Formal release methodolology

[Mitch Bradley]

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 
level.

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.


>  --scott
>
>