[darcs-devel] preparing for the darcs-2 release (and what comes after)

[David Roundy]

Hi all,

I've been thinking about the darcs-2 release (which should be Real Soon
Now--I plan to push a release candidate later today), and what comes after.

We need to change the way we manage the maintenance of darcs.
Historically, every developer we've asked to become a darcs maintainer has
effectively left the project.  Eric hasn't (yet) left, and Tommy's still
here, but is pretty inactive.  But I've been thinking that asking new
developers to take over the role of maintaining darcs is perhaps not the
best way to embrace them into the project.  Of course, it could be that all
these developers would have left the project anyways due to life changes,
but my belief is that a lot of this had to do with the heavy burden placed
on maintainers.  There's also the issue that there aren't really any new
developers in the pipeline who are ready to act as darcs maintainers.

It may be that Eric would step back into the role of darcs-unstable
maintainer (I haven't talk about this with him privately), but I would
rather not ask him, just because I don't want to burn him out.  So I've
been thinking about how we could restructure the maintenance of darcs to
deal with the lower level of contributors that we've got, ideally without
burning anyone out.  My thoughts are as follows.  

I propose to eliminate the two-branch system in which we've got both an
unstable and a stable branch of darcs.  This system has been useful, but it
also effectively requires two maintainers.  Eliminating one branch will
perhaps reduce the total maintenance workload.  The function of the
unstable branch is to try experimental, destabilizing changes.  This
function could be served by private branches, when necessary.  And maybe we
won't have too many more destabilizing changes.

Another issue is that there are too many jobs required of a maintainer.
The maintainers often end up having to manage release issues (building
tarballs, ensuring the docs are built and in the right place, write
announcements), has to maintain the ChangeLog, triage the bug tracker, keep
track of regressions and bug fixes to determine when it's safe to release,
review patches, fix bugs, and discuss new features.  I'm sure I've
forgotten something.  This is a lot of work to do in one's spare time,
particularly when the spare time starts to dwindle because of life issues.

My thought is to reduce the number of jobs expected of a maintainer to just
a few.  The maintainer must review patches, and has to decide when to
release (which is critically related to reviewing patches: determining
which patches are truly "safe" and also which are important enough to
accelerate a release).  Keeping the bug tracker up-to-date needn't be the
maintainer's job, as anyone else can do that.  Maintaining the ChangeLog
doesn't need to be the maintainer's job, as anyone can submit patches to do
this.  Even writing the release notes need not be the maintainer's job.
Putting up tarballs does need to be the maintainer's job.

I should note that many of these jobs have been taken on by folks who
aren't darcs maintainers.  Most notable is Mark, who spend a lot of time
cleaning up the bug tracker and writing up ChangeLog entries.  (Actually,
we could also just do without a ChangeLog.)  But the problem has been that
in the past maintainers have felt (probably modelling after me, who felt
this way) that it was their responsibility that these things get done.

So basically, I propose to continue (after the darcs-2 release) maintaining
a single darcs repository myself, but I'll not do any bug-reaping,
feature-discussing (except the said feature involves a patch), ChangeLog
writing or even release announcements (except for non-PR-like notes to
darcs-devel).  I think I can manage this (for a while, at least), just
reading patches and applying them or replying with suggestions.  It'll
still be a lot of work (unless noone sends in any patches), but it'll be a
lot less than what I've been doing.  We'll see how this works, and whether
it's a good model for future maintainers to follow.

Any thoughts, suggestions, complaints, etc?

David (who obviously is on the brink of burn-out)

P.S. A related issue is that of spreading the darcs.net administrative
burden between more persons than myself.  Right now this isn't too bad,
except when changes need to be made to the buildbot.  One great option
would be for someone else to offer a server for the buildmaster.  Another
would be to not add new build slaves and just let things coast.