From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Carl Worth <cworth@cworth.org>, Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: When will we have our next release?
In-Reply-To: <878vtile1h.fsf@yoom.home.cworth.org>
References: <878vtile1h.fsf@yoom.home.cworth.org>
User-Agent: Notmuch/0.6 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Tue, 07 Jun 2011 09:44:40 -0700
Message-ID: <87r575eglj.fsf@servo.factory.finestructure.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth <cworth@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=20someone 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.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJN7lV5AAoJEO00zqvie6q8OyYP/j+ibcApHlt6dQln9SEPWbMI
CAfI4zMWnwf9pGl/sbiV9BtVKVcYhibCv7BhzZyK2EjtpNhJsky/31HFi3F6RffN
R054XoN/Us2Vsa4Ed/aXK1VWpYeLsv+XOXoZ6nLx7v3fa7rrujJBvNgHGMksP0qs
RARlibPa9r85Mx/4IE4X7CZKNc8sCLyfoAs4gI96NQ5Fg3XTyAY80S5hvVGGECF6
mgjMrSGWOYGAhbfK2DQZriGEOy8SzAgwalr0FxRhZBBg/67vy71s1wALTc00Trmy
ePun0pf9EPLDRBuXz0jGFz23WLrHdviAerYRrlGY16Cb99QbLaDXExa8FET6DtpN
3tTKl17J/9RFunZ+UpQ4YosQ0oiSyFkeafY1anEnFjYRzECH2oH69L1VZ8/8q+6r
B+224n5Zam8/xiwVokgKPSUYrfLKht33kqPPtSjE+LLJvLSHRC/VfMncZwgyEtVo
qBziYh1Bc8yGJ9NWSclZtdpRpKhsvJCHpxakVoQZsdurvanzaUJ1JVZQ5Yho543e
Ocja02ZJJsvROJm6yG5GlfWmyjhzcmIPzeXZb88+VhWqTM+pAS9qhZoEyxkzM+z6
JKGTHNq8u27G/2P7pHPaFXYnyjCAALDPuAeBCuY6WnTzlq9vsObFUHN+jqQW1JHG
ufF81Zw227FnnB+XLbb1
=L2qz
-----END PGP SIGNATURE-----
--=-=-=--