[darcs-devel] The future maintenance of darcs (was: GHC's darcs evaluation wiki page)

David Roundy droundy at darcs.net
Fri Mar 21 16:05:29 UTC 2008


On Fri, Mar 21, 2008 at 11:49:06AM -0400, Mark Stosberg wrote:
> Perhaps the post-2.0 focus should then on the maintainability of the 
> code base while minor bug fixes and new features are on hold.

Indeed, for quite a while darcs has already been nearly unmaintained, and
doesn't seem to have materially suffered.

> I personally expect to find Darcs 2.0 very usable and while I have some 
> "wishes" of things to further improve, none are critical.
> 
> It certainly seems like Darcs has a lot of *users* now. At least, there 
> is an impressive amount of feedback through the bug tracker. Since most 
> users are programmers, and darcs is popular in the Haskell community, it 
> certainly seems there is a reasonable size pool of *potential* helpers 
> even if they are not currently active.

One would certainly think so.  But I'd say the experience of the last few
years suggests that for whatever reason our users aren't interested in
working on darcs.  I can't say why this is, but it does seem to be how it
is.  Could we change this with a PR campaign? Nothing has really worked
yet.  We've gotten a few scattered contributions (for which I'm very
thankful), but noone has stepped up and worked enough on darcs to be
seriously considered as a potential maintainer.

I certainly will continue using darcs, but the amount of time I've spent on
darcs this year just isn't maintainable.  At a minimum, I think we'll need
to give up on having stable and unstable branches, each with a separate
maintainer.

To a large extent, I think darcs has suffered as a result of becoming "good
enough".  The only users for whom darcs isn't adequate are those who use it
with large projects (or for weird purposes, such as managing /etc).  But
those users (e.g. the ghc folks) are precisely those who are least likely
to have much time to devote to darcs.

We also suffer from the fact that darcs uses an inherently less efficient
and more challenging approach than git/hg/etc.

My feeling is that the future of darcs is probably better served at this
point by discouraging large projects from using it, thus remaining the
niche where we already are successful.  If large projects using darcs gave
us any additional developer momentum, that would be one thing, but that
doesn't seem to be the case.  So it seems best to simply acknowledge that
darcs doesn't work well on large projects, and that's just the way it's
going to be.
-- 
David Roundy
Department of Physics
Oregon State University


More information about the darcs-devel mailing list