Formal release methodolology
wmb at laptop.org
Tue Feb 5 15:54:01 EST 2008
C. Scott Ananian wrote:
> 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.
Indeed. And the problem is that our current "request approval for
update" mechanism requires the developer to be the champion for a
particular version. At the moment, I for one am not willing to take
that role; I just don't want to fight the battle. And I get a similar
sense from dilinger's posting. I have been restricting recent firmware
releases to changes that have some possibility of making the cut, but
the decision about where the final cut lies needs to be made at a higher
Filing bugs in trac records issues, but does not cause decisions to be
made. The thing that is missing is the decision process - who is
responsible and authority for making decisions, and what process ensures
that decisions are made and communicated. The process needs to be
proactive, rather than having developers throw stuff at the "request for
inclusion" wall. "Request for inclusion" is fine for getting new stuff
in, but it sucks for deciding which version of an existing core
component to use at a given time.
More information about the Devel