[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[platform-releng-dev] 3.1 endgame plan
|
The 3.1 endgame plan is posted here (no interesting changes from what was
proposed):
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/eclipse-project-home/plans/3_1/freeze_plan.html
Starting tonight, we will be producing an *integration* build from HEAD.
Each day, we expect everyone to upgrade to the previous night's
integration build. This should allow us to move quickly and discover
unintended side effects sooner rather than later. Obviously, we need these
builds to work. Please ensure that all changes released to HEAD are solid
gold.
Send me updates to component test plans and I will integrate into the
document linked from the endgame plan.
---jim
Jim des Rivieres/Ottawa/IBM
04/28/2005 07:37 PM
To
platform-releng-dev@xxxxxxxxxxx
cc
Subject
proposed 3.1 endgame plan
After a number of conversations today about how to best structure the 3.1
endgame, here's what we came up with (consider this still a proposal until
everyone has had a chance to digest and comment).
We make an immediate (May 2) transition to fixing and polishing mode for
all Eclipse component teams, reflecting the fact that most teams have
already finished all their feature work for 3.1. The focus becomes the
current backlog of bugs which needs to be prioritized, and then reduced.
The few teams with additional feature work need to obtain PMC approval to
complete that work; all feature work is expected to be done by M7 (May 13)
as originally scheduled. The point is not to cut off feature work
entirely, but rather to strike the right balance between last-minute
feature work and addressing serious bugs, especially if there's already a
backlog of bugs also need attending to. After M7, all work is on fixing
serious defects, performance, and on special polish items. The work on
special polish items is done by RC1 (May 27).
We immediately (May 2) start nightly integration builds from HEAD leading
up to milestone M7 scheduled for May 13. M7 will also be our release
candidate RC0. The difference from the nightly builds is that all teams
are expected to pick up and work with the nightly integration builds. This
puts a premium on keeping HEAD viable at all time, and requires disciple
from all committers to ensure that the bug fixes and approved feature work
they release to HEAD do not destabilize any of these integration builds.
This is the one area where we've become complacent and dropped our guard
for some of our recent integration and milestone builds. We will be
depending on the committers to tame their desire to fix as many serious
bugs as quickly as possible with the reality that we only have a limited
amount of time before 3.1 goes out the door, so we need the right fixes to
the right problems. There will be time for further fixing after M7, so no
one should feel that M7 is the last chance to get the fix in.
On Tuesday and Wednesday May 10-12, we do a full 2-day all-hands test pass
to ensure that the new feature in M7 are up to snuff, and to ferret out
any serious bugs lurking anywhere. This is one more day of testing that we
usually do for our milestones, and gives us a good chance to shake the
tree hard to see what falls out. On Thursday May 12 we would fix any bugs
that would reflect poorly on M7, but likely defer until after M7 fixing
long-standing problems that had never come to light before. We would put
together a M7 new and noteworthy as usual describing all the interesting
features that were added since M6.
After M7 is out the door, we have 2 full weeks of bug fixing, performance,
and special polish before RC1 (Fri. May 27). RC1 is followed by 2 day test
pass (May 31-June 1), followed by bug fixing until RC2 2 weeks later (Fri.
June 10). RC2 is followed by 2 day test pass (June 13-14), followed by bug
fixing until RC3 exactly 1 week later (Fri. June 17). RC3 is followed by 1
day test pass (June 20), followed by surgical bug fixing until RC4 (Fri.
June 24). RC4 will be promoted to 3.1 release by Thursday of the next week
as scheduled (and exactly 1 year since we shipped 3.0).
That adds up to a total of 7 days of testing until we're done. Sounds like
light work, given it's spread over 2 months. And especially when compared
to the number of bugs that we'll fix between now and then.
A draft endgame plan with all the dates is posted here:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/eclipse-project-home/plans/3_1/freeze_plan.html
I've spoken with several of the component leads and know right now of only
2 that have feature work that will not be completed this week. I'll
contact the rest of you tomorrow to find out if there are any other teams
in this position.
Please send any comments or suggestions to this list.
---jim