bzr 2.1 retrospective

[Stephen J. Turnbull]

Ben Finney writes:

 > > * change: Insist on zero changes between the last rc and the final
 > > release? This may be waste though; making the release takes some work
 > > and it's not necessarily worth doing another cycle to squash the
 > > probability to absolutely zero.

It's a waste, and impossible anyway.  My predecessor at XEmacs once
changed only the version number (to remove the "rc" designation) in
version.sh, and got a crash (it was a really stupid version check in
the startup code, buggily implemented to boot).  You can't get the
changes to zero, and therefore you can't reduce the probability that
you get a new manifestation of a bug to zero.

 > I think the correct answer there is to work on getting the release so
 > it's *not* a significant hassle to make one.

You're both missing that point that you *are* going to run the
regression tests which should catch anything amazingly braindamaged.
So what really matters is getting the beta testers to beat on an extra
RC just on the 6-sigma chance that a new bug manifests after trivial
changes.  Even if the effort for the release manager goes to zero,
you're still thrashing the testers, and delaying the release.

 > How do primarily-Windows projects deal with automation of packaging,
 > then?

They pay a release manager to do it.<duck />

 > Should Canonical be seeking explicit donation of resources (time on
 > external machines, etc.) to make use of those techniques that
 > automate such a build?

Canonical can surely afford the machine time.  The problem is
developer time to ensure a high-quality package, for which I don't
think you want to depend on donations from people otherwise not
associated with Bazaar development.

Python itself has a number of people working in primarily Windows
shops and they (mostly Martin van Loewis, I think) do the packaging.
Why not ask them for advice?