[rfc] six-month stable release cycles

John Arbash Meinel john at arbash-meinel.com
Wed Jul 29 19:00:55 BST 2009

Hash: SHA1

Guy Gascoigne-Piggford wrote:
> Strongly seconded.

Just to mention, I've *often* released a X.Y-2 or even X.Y-3 because of
packaging issues. I haven't done one for 1.17 specifically, because it
is unclear what actually needed to be done. (I think it needs a newer
bzr-rebase/rewrite, though not positive.)

I *don't* think we need to release 1.17.1 because packaging failed. That
is why the packages are labeled 1.17-1, as the final -Z indicates the
*packaging* release number. Failures in packaging bump the packaging
release number, not the bzr release number.

If someone wants to propose a reasonable fix to get the all-in-one
installer working (like telling me "use bzr-rewrite-0.5.100", then I'll
go package one and let you poke at it.

I would like to see packaging work a little better than it does today.
We have some work from Sidnei da Silva to get a continuous build process
via buildbot. (Not complete yet, or at least, not up to date.)

However, there is a fairly large overhead in dealing with packaging,
which is then compounding the difficulty of managing a release. And when
you do at least a minor release 1/mo you want that to be a simple as you
can make it.

It would probably be good to have an item on a RM's checklist to go poke
the people who build installers a couple of days after the official
release has gone out.

I'm *never* going to promise day-0 packages. Between coordinating
timezones, vacation schedules, level of development activity, bugfixing,
etc. Packaging is important, it certainly isn't the most important thing.

Heck, when we get to the point of stable-every-6-months... if you are
running code that is 6mo out of date, does it really matter if it takes
an extra day to get it to you?


Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the bazaar mailing list