When will we have our next release?

[Carl Worth]

On Tue, 07 Jun 2011 09:44:40 -0700, Jameson Graef Rollins <jrollins at finestructure.net> 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.

Excellent!

> But the mechanics of the actual release are not the problem.  The
> problem is the current one-person bottleneck for all patches:

This is a problem if master isn't moving, I agree. And that has been a
problem in the past.

More recently, master has been moving just fine, and I have proven to
get too caught up in "oh, just a few more bug fixes to merge..." to just
sit down and make a release. So that's what I want to fix now.

To that end, I've just nominated David Bremner as our release
manager. He's already been pushing packages of recent notmuch master to
Debian experimental, so he's effectively already in the role of choosing
particular code states that the "masses" can easily get their hands on.

I've asked him to just take over the release process from here and I've
pretty much left all decisions in his hands. He'll probably make a
separate branch for the release at some point, (in the primary
repository). I'll let him talk more about plans if he needs to.

> 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.

Thanks. That's very kind of you to say so.

> 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.

I can't really promise anything other than doing the best I can to stay
on top of things. Lately, I am at least using notmuch itself more
effectively to manage outstanding patches and this is helping I thinl.

> 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.

Yes! For people that are already effectively maintaining isolated
portions of the code, I'm more than happy to delegate full editorial
control over those pieces, (and allow direct pushes, etc.). This has
actually already been happening with python and vim pieces. And I plan
to add some new mutt code soon with its own maintainer.

And the delegation of release management that I'm announcing here will
help too.

> 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 have more review from anyone. I don't think there's any
need to formalize anything.

Much of it can be as simple as watching things you've seen me do and
then doing them yourself. For example, there are a lot of recent patches
that I merged only after I wrote a test case for the bug fix. It's quite
a bottleneck for me to write new tests like that. If other people could
review patches and ask for test cases, or write test cases themselves,
then that would definitely relieve a burden on my part.

Similarly, I think the most regular coders on the project have come to
understand what I expect from commit messages. So that's something else
that's pretty easy for anyone to review.

So, yes, please help in the review process, everybody! I don't think I
have any particularly exclusive talent with regard to judging code to be
clean and in good taste. I definitely appreciate the good sense of taste
that many on this list are demonstrating regularly.

> Notmuch is an incredible project, with an absolutely incredible
> development community.  It's an absolute joy to work on.

I absolutely agree. I haven't taken the opportunity often enough to say
thank you to everyone who has contributed!

So, thanks!

It's such a wonderful thing to me to see so many good people working
hard and having fun to collectively make such a fun tool![*]

> 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.

Hopefully, we're doing that. Thanks for all your efforts, Jamie. I
really appreciate them. And I'm happier at least!

-Carl

[*] For "fun tool" I always have to hesitate a bit—notmuch itself is
fun, but it's funny that email itself is often more annoying to me than
anything else. I suppose what makes notmuch fun is that it helps me more
quickly eliminate so much of the annoyance of email from my life so that
I can focus more on the things that I really want to.

-- 
carl.d.worth at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110622/fe0ecb45/attachment.pgp>