> By the way, this is my first mail to darcs-devel. Welcome aboard! Looking forward to seeing your first patches.
> So... I'm jumping in. I don't think it's currently a very good time > for "casual hacking" in darcs, because all the new (still > undocumented) stuff about hashed repositories and new conflict > resolution, but count me as part of the community :). Now is a fine time for casual hacking. There is plenty of work to do which does not require knowing about the hashed repositories or the new conflict resolution (etc). Moreover, whilst the theory-core people are working on these things, the rest of us had better pick up the pace (he says hypocritically) on the other stuff. Life must go on. Here are three things that a new developer might consider working on, none of which requires worrying about the new stuff : * amend-record --edit-description I keep changing my mind about what I wanted to put in the patch description. I'm sick of the unrecord/record cycle. * single-file _darcs/pristine Using something like HalFs to store the pristine cache so that neither Unison, your fancy IDE, or stupid sed tricks will corrupt your darcs repository * interactions between flags, like changes --repodir and --context or send --edit-description -o And finally a silly opionated rant ---------------------------------- Also, maybe those of us on the fringe (who are not busy drawing crazy commutation diagrams) should invert our priorties. Our efforts should be spent bashing away at the bug tracker, finding *easy* things to fix and getting rid of that stuff first. It's an issue of bang for buck, similar to the idea that anything which takes < 2 min should be done immediately because the time it takes to put it on your todo list, or to keep recyling 'crap, I have to get around to that' in your head is colossal with the two minutes it would have taken to get it over with in the first place. Having things rot in our bug tracker is like a perpetual 'crap, I have to get around to that'. It also obscures away the true issues, drowning away the really worrying stuff in a sort of noise. I used to think that maybe it would be better to leave ProbablyEasy stuff to new developers, as a sort of recruitment/training tool, but I don't think that's working in practice. The problem is that this just makes us stagnate. We don't get around to doing the easy stuff because it'll be good training for the newbies (eric 2005), but we don't get around to doing the hard stuff either (medium hard fringe stuff), because, well it's a big investment, and oh look, there's Digg/reddit. Perhaps fixing the easy stuff will be better for darcs's popularity, which will in turn inspire more people to become developers. And besides, new easy stuff to fix (and to train developers with) is a highly renewable resource. Just ask Zooko. So that's my proposal. Forget priorities (*). Let's all start with the easy things. (*) although as one redditor has already complained, we don't have a notion of priorities. -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français.
pgpoD1ZMY8H9n.pgp
Description: PGP signature
_______________________________________________ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel