On Fri, 03 Jun 2011 14:39:13 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> Can we set a target date for 0.6 release?  So we'll all start feeling
> really bad if we miss it?

Frankly, I wouldn't mind doing strict time-based releases with something
like the following:

	* We schedule a release period (once per month?)

	* We schedule a "safety period" before the release (one week?)

	* At the beginning of the safety period, package up the head
          of the notmuch tree and upload to Debian experimental and
          anywhere else similar.

	* During the safety period we hopefully get wider testing than
          we normally have from just the git master branch.

	  If any bugs are found and fixed during this time we can create
	  a branch for them. New feature work can continue to land on
	  master.

	* At the end of the safety period we package up the same bits,
          or the new bits from the cherry-picked fixes on the branch,
          and upload them to Debian unstable and anywhere else similar.

I'd even be happy for someone else (other than me) to run that process.

That might be beneficial for a couple of reasons:

	* It would simply take one thing off my plate.

	* I'm inclined to do feature work myself---and when I start
          doing that again, I might get tempted to delay the release
          "just until I finish this next feature...".

I think that's the problematic state we've been in for the past several
months. Right after 0.5 I thought "I should do some database changes to
support indexing/searching of arbitrary headers and to capture complete
email addresses". I've not actually gotten around to doing that work
yet, but I was a bit stuck mentally in "the next release will have those
features" so there was never any threat of a release actually happening.

So switching to a more strictly time-based cycle can definitely help,
(so many other projects use time-based releases very successfully).

Now, in order to hand the release process over to someone else, we need
a really simple "just push this button" mechanism for the release. I
think we've got that pretty-well in place right now, with the large
exception of writing the NEWS file.

So the fix for that is to start rejecting patches that add features or
fix user-visible bugs (other than regressions since the past release)
without also updating the NEWS file. I'll commit myself to doing that
for my own bug fixes and features as well.

I also think it's possible for me to be successful as the release
manager as long as we decide on a schedule as a community and that way
you all keep me to it.

The current state of keep-coding-until-we-have-a-state-good-enough-to-
call-the-next-release does have the potential to keep running on
forever.

I'd be glad to get any feedback or additional ideas from anyone,

-Carl

-- 
carl.d.worth@intel.com