[
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/mylynSenior Developer,
http://tasktop.com
