C. Scott Ananian wrote: > On Feb 5, 2008 1:50 PM, Mitch Bradley <[EMAIL PROTECTED]> 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 > > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
