[rfc] six-month stable release cycles

[Martin Pool]

2009/7/30 DeeJay <smartgpx at gmail.com>:
> My last shot tonight. I didn't intend this to be a dialogue...

(Why do you keep starting apparently separate threads for every
message?  Did you realize you're doing this?)

>
> "We have at least 1 week of RC w/ an rc installer before the final build
> is made. I've certainly gotten some feedback during that time. And even
> though we don't have the full week from installer before -final is
> released, it is usually the same lag for building installers."
>
> 1] There were no Windows standalone installers for the RCs of 1.10,
> 1.14 and 1.15. (Perhaps that's before John was on the case.)
>
> 2] In the case of 1.17 a new problem was introduced into the Final
> release that was not in the RC. 403789
>
> Of course the final arbiters of the success of a release are the end
> users, but just as with the source code for the core, aren't there
> some 'smoke tests' and selftests that could/should be run before an
> installer is published?

People do run smoke tests, but 'bzr help commands' wouldn't be high on
the list of things to test.  I don't know if they run bzr selftest on
the installed copy; I think at the moment there are some
platform-dependent failures.

> And my point was not that John, or whoever the current volunteer
> packager is at any given time, is 'failing', but that since for
> Installer users the installer IS the bzr release perhaps the testing
> should be done as part of the 'core' release process?

No, this is not going to be part of the 'core' release process.  The
RM's job is big enough already, and we should be aiming to break
things into smaller tasks and to eliminate dependencies, not the
opposite.  Making a Windows installers requires having a Windows
machine, doing nontrivial setup on it.  Because experience helps you
do both the RM and the packaging jobs, we don't require all that work
be on one head.   There's also a lot of value in allowing different
types of packaging and testing to occur by different people in
parallel.

Now although it may not be part of the core release process, I do
think it's something we can aim to do before the general announcement,
by separating out code freeze and announcement.  There will be a
window during which binaries can be built to be included in the
announcement.  From the user's point of view, there will be binaries
on day zero (and there was code on day T-5, say).

I think the most pressing question here is, how do we get more
horsepower onto the whole Windows release process, and not leave it on
John's shoulders.  Can we do anything that will get one of the people
who feel strongly about the installer to help with building it?  What
is stopping them at the moment?  We have a few things from this
thread, or already in train:

 * a Windows buildbot to keep it more clear
 * gradually avoiding spurious or unexpected failures on Windows
 * making the installer build process more automated
 * allowing a specific time slot in which this can happen
 * Windows nightly builds

-- 
Martin <http://launchpad.net/~mbp/>