Formal release methodolology

[C. Scott Ananian]

On Feb 5, 2008 1:50 PM, Mitch Bradley <wmb at laptop.org> wrote:
> FYI, here is how the firmware team (i.e. Richard and I) implement the
> release-stabilization parts of the above.  I do not address the formal
> testing here, just the special disciplines during run-up-to-release.
[...]
> d) As of the last couple of spins, our release procedure includes
> building an RPM for submission to Dennis via the "joyride" injection path.

I think the only missing piece here is someone gating which 'joyride'
firmware builds should ultimately go into stable builds.  For example,
"yes, q2d10 is in joyride, but we've already got bug reports on it;
until we've got a better candidate, q2d09 should go into the stable
release candidate" vs "yes, q2d12 is expected to go into the next
stable release".

"The latest thing in joyride" isn't always the appropriate thing for a
stable release, especially for point releases, etc.  So we need some
mechanism, whether it is filing bugs in trac or something else, for
Dennis to know when and if a new version should be put into a release
candidate, and why.
 --scott

-- 
                         ( http://cscott.net/ )