> 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.

Attachment: pgpoD1ZMY8H9n.pgp
Description: PGP signature

_______________________________________________
darcs-devel mailing list
darcs-devel@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel

Reply via email to