[asdf-devel] Question about git

[Robert Goldman]

On 1/30/10 Jan 30 -7:08 PM, Samium Gromoff wrote:
> From: dherring at tentpost.com
>> To me, a more interesting question is whether people might find a site
>> like github or gitorious to be helpful.  Such sites have systems for
>> making and auto-tracking forks, submitting merge requests, administering
>> commit bits, etc.  Github is more individual-oriented; Gitorious has a
>> more team-oriented focus.  Theoretically, gitorious could even be
>> installed on cl.net.
> 
> To me, such a thing definitely screams of potential.
> 
> We need as much integration as we can get.
> 
> Now, the question is, who would feel like participating in definition
> and maintenance of such a structure..

Um, with all due respect, I'd prefer not.

The switch to git has already sucked a lot of cycles away from
development for me.  Maybe CVS sucked, but it didn't take any of my time
to learn it (sunk cost), and it did all I needed to have done.

I'd really prefer that we /simplify/ the process of developing ASDF so
that I can spend more time on that and less time fighting what's
supposed to be a tool.

It seems like you all are saying that the solution is to add /more/ git,
more forking, more administration.

All of the items in that email "Such sites have systems for making and
auto-tracking forks, submitting merge requests, administering commit
bits, etc." all seem to be opportunities to have systems that will help
make our lives more complicated, not easier.

Isn't all this forking wild overkill for ASDF?  OK, if you're developing
the linux kernel and drivers, yes, you might have a very long-lived
branch to develop or restructure a file system or something.  But ASDF
is really, essentially, a single file.  You can't have a long-lived fork
in a single file without horrible problems merging.  I don't care how
great your version control system is, down at the bottom, what you've
got is diff, and diff is not that great a tool.  Similarly, given the
size of the ASDF developer community, is it really worth it to invest in
a tool that will administer the commit bit?  Is there any chance we'd
recoup the tool investment in labor savings?

As far as I can tell, a development model where you pull the head, start
a local branch, fix something on your local branch, submit the patch to
Fare, and then kill your branch, is all anyone is going to need or want.

[Well, I suppose if you're responsible for a lisp implementation, you
might want a persistent branch to keep specific add-ons, but even that
doesn't work terribly well in a one-file system.]

Until we know exactly what we'll get --- and not what we'll get with
respect to cool features, but what we'll get with respect to features we
might actually use in ASDF development and maintenance --- I think we
need to keep a very careful eye on the cost/benefit tradeoffs here.

Best,
r