When will we have our next release?

Jameson Graef Rollins jrollins at finestructure.net
Tue Jun 7 09:44:40 PDT 2011


On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth <cworth at cworth.org> wrote:
> Frankly, I wouldn't mind doing strict time-based releases with something
> like the following:

Hi, Carl.  I think this is a fine idea, and we (not you) can definitely
run this process.  I'm quite sure that at least bremner and I can
completely handle this together, and I'm sure we can get others to help.

But the mechanics of the actual release are not the problem.  The
problem is the current one-person bottleneck for all patches: your
review and merge of all patches into the notmuch/master branch.  This
would not necessarily be a problem if you could get to reviewing and
merging patches more frequently.  But as it is now, if there are no new
patches on notmuch/master for longer than the release period, there will
be nothing to package and upload.

This is *not* meant to be an indictment of you at all.  I know it's
incredibly hard to keep up with the incoming patch flow.  It takes a lot
of time and work to review every patch.  I also really like your
reviews.  They are incredibly thorough and insightful, and I always
learn from them.  Your intimate knowledge of the code base also means
that you can frequently come up with cleaner solutions to the proposed
patches (as with the reworked part handling).

However, the bottleneck presents a big problem when delays are
introduced.  We can't really do anything until you can get to the
review.  Furthermore, even if we do push ahead to put together a release
candidate branch (as we did with 0.6), if your review severely alters
patches early in that branch we have to do a lot of work to rework their
decedents (as we did with 0.6).  This leads to a lot of inefficiencies.

So we need to figure out a way to break the bottleneck.

I would really like to continue to get your review of patches.  I think
they're just too valuable.  So it would be really nice if one of the
solutions was a way to just "grease" the bottleneck, so to speak.  For
instance, if you could commit to reviewing just 1 patch series a week we
would be way ahead of where we have been.

Another thing that would help would be to delegate responsibility of
certain components to others, as you have with the python binding to
spaetz.  For instance, we have at least a couple of elisp experts
hanging around.  Maybe you could cede handling of all emacs patches to
someone like jkr or dme, and to felipe for vim, etc. (if they're willing
to take on those rolls).  That would help reduce your burden a bit.

We could also formalize some sort of tiered review system.  amdragon has
been doing a really good job of frequently providing good review of
patches on list.  I think that any proposed patch that gets a thumbs up
From someone like amdragon should immediately be elevated in your queue,
or just applied out-right.  If the review of others explicitly helped
get patches merged faster, I'm quite sure it would encourage more folks
to submit their reviews as well.

I would love to hear any other ideas people have on this front.

Notmuch is an incredible project, with an absolutely incredible
development community.  It's an absolute joy to work on.  If we can just
grease the wheels a little bit to get releases out the door a little
quicker, I think we'll all be a lot happier.

jamie.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110607/925b248f/attachment.pgp>


More information about the notmuch mailing list