[linuxtools-dev] Final contributions for 0.6 (Helios release) due June 8

[Andrew Overholt <overholt@xxxxxxxxxx>]

Hi,

See below for the procedure we'd have to follow to include a new build
in Helios after our contribution next Wednesday.  I really don't want to
be the project to cause rebuilds so everyone please do lots of testing
and find any major bugs between now and next Tuesday (June 8th) so we
can fix them.

** All commits over the next 5 days must have an associated bug **
** All commits over the next 5 days should be reviewed by at least one
   other committer **
** All commits over the next 5 days should have a test case to verify
   that they do indeed fix what they intend to **

On Wednesday June 9th, I'll do a final, signed build and push it to the
Helios repository.  Then I'll branch and tag.  The following week gives
us time to do last minute testing and get our web collateral
(N&N, documentation, etc.) in order.

As usual, ask if there are any questions.

Almost there!

Andrew

----- Forwarded message from David M Williams <david_williams@xxxxxxxxxx> -----

> Date: Thu, 3 Jun 2010 00:36:34 -0400
> From: David M Williams <david_williams@xxxxxxxxxx>
> To: cross-project-issues-dev@xxxxxxxxxxx
> Subject: [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.
> 
> 
> 

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


----- End forwarded message -----