Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 25860431FD0 for ; Wed, 22 Jun 2011 18:21:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+kVLy+uJKCJ for ; Wed, 22 Jun 2011 18:21:16 -0700 (PDT) Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2]) by olra.theworths.org (Postfix) with ESMTP id 1D93A431FB6 for ; Wed, 22 Jun 2011 18:21:16 -0700 (PDT) Received: from yoom.home.cworth.org (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 910F829A4FB; Wed, 22 Jun 2011 18:21:14 -0700 (PDT) Received: by yoom.home.cworth.org (Postfix, from userid 1000) id 83702254157; Wed, 22 Jun 2011 18:21:14 -0700 (PDT) From: Carl Worth To: Jameson Graef Rollins , Notmuch Mail Subject: Re: When will we have our next release? In-Reply-To: <87r575eglj.fsf@servo.factory.finestructure.net> References: <878vtile1h.fsf@yoom.home.cworth.org> <87r575eglj.fsf@servo.factory.finestructure.net> User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu) Date: Wed, 22 Jun 2011 18:21:08 -0700 Message-ID: <874o3hfim3.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 01:21:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 07 Jun 2011 09:44:40 -0700, Jameson Graef Rollins wrote: > > Frankly, I wouldn't mind doing strict time-based releases with something > > like the following: >=20 > 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! =2DCarl [*] For "fun tool" I always have to hesitate a bit=E2=80=94notmuch 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. =2D-=20 carl.d.worth@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4ClQQACgkQ6JDdNq8qSWicwACfWlA+8VfDxkl9Qk2pc/AIXYaz 5jUAoJEKj6UPkQbEs1fuXw02DGKdSCJV =+VI9 -----END PGP SIGNATURE----- --=-=-=--