On 1/30/10 Jan 30 -7:08 PM, Samium Gromoff wrote:
From: dherring@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