[rfc] six-month stable release cycles

Maritza Mendez martitzam at gmail.com
Wed Jul 29 21:57:20 BST 2009

On Wed, Jul 29, 2009 at 11:00 AM, John Arbash Meinel <john at arbash-meinel.com
> wrote:

> 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?
> John
> =:->
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> P/oAoMMNoCrucDaiOXnPOnLjJ46oT3eR
> =Pp9e

I agree that packaging is important in general and especially important for
releases labeled "stable."  This has been a subject of discussion recently
on the list and actually is improving to the extent that people like John
and Guy (and others!) have been able to step up to do the work and provide
feedback.  Make no mistake, packaging is a *big* job -- as big as it is

That said, I also think the proposed stable branch helps to alleviate the
problems some of us may have experienced with the current release process.
If it takes a week to get an installer built for the stable branch, that may
be ok for people using the stable branch.  It is stable, after all.  As for
the development branch, well, anyone who *needs* those should also know how
to build their own installer if need be.

We use a system like this internally at my company.  People who need (or
want) to track the bleeding edge accept the extra responsibility of being
mostly self supporting.  People who just need a stable tool wait for the
installer on the stable branch.  It works well, because we have clearly
defined stable and development branches.

And what *really* helps is that we do not announce a stable release until
the installer is built and tested.

What I'm saying in too many words is that I think the installer availability
situation can improve under the new release proposal, because only the
stable branch needs installers and they can be delayed for QA without
slowing down the core developers.  This is just my two cents as a bzr user
who just happens also to be a professional developer of other products.
This works for us, but maybe not for everyone.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090729/a9e139fa/attachment.htm 

More information about the bazaar mailing list