Skip to main content

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

The Mylyn RC4 build with the version 3.4.0.v20100608-0100 is now available from the Mylyn weekly site.

Committers (and anyone else who wants to help testing), please give that build a spin and post if there are any blockers. We still have a good 12 hours in case we need to do a rebuild. After that automatic Helios builds will get turned off and pushing changes to Helios will require PMC approval.

Steffen


On Wed, Jun 2, 2010 at 10:03 PM, Steffen Pingel <steffen.pingel@xxxxxxxxxxx> wrote:
Below is a summary from David Williams of the final daze for Helios. It's a good reminder that we have only one week left for fixes and polish before the bits are (mostly) frozen.

Steffen

---------- Forwarded message ----------
From: David M Williams <david_williams@xxxxxxxxxx>
Date: Wed, Jun 2, 2010 at 9:36 PM
Subject: [cross-project-issues-dev] Ready for your final Helios build?
To: cross-project-issues-dev@xxxxxxxxxxx



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.




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




--
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com



--
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com

Back to the top