[darcs-users] on the eventual transition to a commit-bit model

Eric Kow kowey at darcs.net
Mon Aug 3 17:55:27 UTC 2009

On Mon, Aug 03, 2009 at 15:54:19 +0200, Petr Rockai wrote:
> If we adopt the commit bit approach, I would probably welcome a system, where
> people would only push patches that they are not authors of. Basically, this
> would just streamline the current process: someone reviews a patch and then
> pushes it into mainline, instead of telling you to push it. We may ponder a
> little about allowing testing coverage to partially substitute for review. I
> don't know, really. I think it's still your call, since you are the maintainer.

For those of you who don't follow the IRC channel, this conversation may
provide a bit more context:

I think it's time to continue our movement away from a central
maintainer model towards a commit bit one.  We've been a natural
progression from one maintainer, to an unstable/stable split, to an
unstable/stable split with fast tracking of trivial patches to stable
and most recently to a formal Review Team with a purely functionary role
for the maintainer (basically, a "Patch Manager").  Now it's time to
streamline the process (as Petr says), to take one more step in this
direction by opening up the darcs push rights a little bit more.

My main reason for pushing for this (and also for shifting towards a
Review Team) is selfish :-).  As much as I want to see the Darcs project
thrive, to see us make good and smack down once and for all that silly
idea about things being "good in theory and bad in practice", I also
don't want Darcs to be taking over my life.  The role as I'm currently
playing it mostly takes care of itself but if I can streamline it one a
little bit further, all the better.

Of course, viewed from the other side of the coin, I think this would be
good for the project in Bus Factor terms.  The idea is to move Darcs
towards towards a more stable model of development, where babies,
illness, or sudden onset of busyness at work for any one developer do
not cripple the project.  The cost of spreading things out is the
potential for things to slow down and also to get discussed at greater
length (which is actually a good thing if you don't mind long threads).
But it does mean we get more stability out of it.

We don't want to find ourselves drowning in policy.  Just something
simple that does the job.  Kinds of questions we might ask ourselves:

1. Who gets a commit bit?  I think most conservative version of this
   would be to say that anybody who is on the Review Team gets a bit.
   A very liberal model might to say, for example, that anybody who
   has had 3 patches accepted is eligible.  Since we have distributed
   revision control, I'm actually quite happy to consider a liberal
   model.  Worst case, we agree to restore the repo from an older

2. How does one become a committer?  If we go the Review Team route,
   we can keep the conservative route of making it by my invitation.
   If we go the liberal route, it's fairly clear.

3. When can a committer push patches?  Basically, I think we should
   retain the review-centric culture until we've done more work on
   tests (particularly, getting a better understanding of what we
   need to do to improve our testing coverage).  The general
   approach of everybody sending patches to the list, to be reviewed
   and pushed by somebody else is probably a good one to keep.
   Typos and trivial patches could be an exception.

[A] We now have automated HPC telling us our test coverage:

[B] Petr says he's been meaning to put together a new buildbot
    waterfall with only maintained buildbots.  Alternatively, I
    think we could just cut the nightly snapshots and prune the
    build master we have.

[C] Some sort of patch tracker could be useful if we also want to
    reduce the role played by the patch manager:

[A] is done, [C] may perhaps be investigated by Max Battcher if he has
time, but is not totally essential.  That leaves [B] which I think
should be treated as essential.

Thoughts? :-)

Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090803/f2d47a6b/attachment.pgp>

More information about the darcs-users mailing list