Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cross-project-issues-dev] Ready for your final Helios build?

What? RC3's not even completely done. And what happened to RC4?

Well, RC4 should indeed be your final build ... and clarifying that is the purpose of this note.

Our plan document isn't perfectly clear, and at today's Planning Council (PC) meeting I was reminded of that.

You'll notice the summary has RC4 ending on June 11, and then the release a little over a week later on June 23.
That is and always has been intentional. The goal is to have a full "quiet week" before the release to give projects time to do some in-depth testing and
for adopters to do their own final builds and their own final testing. The idea isn't so much to "find and fix last minute bugs" but instead to "find last minute bugs, so
at least they are known about before the actual release".  

But, the calendar below the summary has some "Final Build +n" dates scheduled after RC4. That would have been better documented as "builds on demand for exceptional cases".

Elsewhere, we do say "The Final week before GA will not have any further builds or contributions, but instead be reserved for final adopter testing and preparation and only emergency fixes for very serious regressions will be considered."

So, not documented well, but here's the process we arrived during the PC meeting:

A. Automatic (aggregation) builds will be turned off after RC4 is done (June 10).
B. If a project (and their PMC) really think they have one of those "emergency fixes for very serious regressions" type bugs, they can post a note here to this cross project mailing list.
The note should explicitly request a rebuild, explain why its such a bad bug and why its so important to fix before maintenance (and give the bug number, of course). This is mostly to keep everyone informed, and slow everyone down so
each change in carefully considered, but also ...
C. If the PC Lead (currently me :) thinks it is reasonable, the button will be pushed and a rebuild of the repo will take place. If there's some doubt about if it is reasonable, I will ask for further review from PC and/or the project's PMC.

Remember, that projects can provide their own maintenance any time they want to, so bugs in this very serious category should things like "maintenance can not be applied without this fix" or "reformats hard drive when installed" or maybe "project X's code prevents project Y's code from running". Not things like "menu is not disabled when it should be".  This quiet week is very important, since changes made during this final week could not be fully, adequately tested (in combination with everything) and we must avoid any embarrassing regressions showing up in the released code.  

And remember, even with this "minimal change" process, it is easy to break the build if any project (even unrelated to the desired change) changes any thing in their own repos ... so, please don't change anything and be sure our builds stay reproducible throughout this final week. If the build is not perfectly reproducible (except for the desired change) then we'll have to drop back to RC4 and release that.

Each case is different (which is why its called and "exception" :) and of course we do want a high quality release, so don't hesitate to discuss issues here on cross-project list, if something is in doubt.

We are here to help. Thanks for yours.

Back to the top