[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Eclipse 3.3 endgame plan
|
Sorry. Let me clarify.
First, if we had copied the 3.1 end game plan and changed the dates to make
it the 3.3 game plan, it would have been great.
The 3.1 release remains my favourite release of all-time. It was pretty
solid in both stability, performance and abundance of features.
Now on to this end game plan:
I am in favour of restricting the 'fix approval' to component leads rather
than any committer, because at the end of day,
it is the component lead's responsibility to ensure stability in their
component.
This is the part that JohnA got out of my previous note.
Toward RC2, there seems to be a need for more approvals than the component
lead.
This part is new and may be too much. We did not have that in previous
releases and we were doing just fine.
As for the 'Extra Checking' requirements,
I think that having an extra pair of eyes to check over the code is
certainly not a bad thing.
So while they were newly introduced in the 3.3 end game plan for RC1 and
RC2, that's not a bad idea.
If some teams feel it's too much process, then it may seem reasonable to
make this part optional for RC1/RC2 (as we did in previous releases).
I think, at the end of the day, we all want a smooth end game that is not
over-restricted with approvals and having to track down people to get their
+1's.
I understand the need to do so for RC3/RC4, but not for RC1/RC2.
This is the part that Dejan is referring to.
Since we have had a process that worked for us very well in the past,
I am not sure why we need to change it.
I mean that Eclipse 3.1 was unbelievable!!
Thank you,
Wassim
John
Arthorne/Ottawa/I
BM@IBMCA To
Sent by: "General development mailing list
eclipse-dev-bounc of the Eclipse project."
es@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
cc
05/02/2007 05:19 Subject
PM Re: [eclipse-dev] Eclipse 3.3
endgame plan
Please respond to
"General
development
mailing list of
the Eclipse
project."
<eclipse-dev@ecli
pse.org>
I think Wassim is suggesting that the new endgame plan is *less* strict
than the previous plan, because it only requires "any committer" to approve
the fix, rather than the component lead.
Dejan Glozic/Toronto/IBM@IBMCA
Sent by: To
eclipse-dev-bounces@xxxxxxxxxx "General development mailing list
g of the Eclipse project."
<eclipse-dev@xxxxxxxxxxx>
cc
02/05/2007 04:58 PM "General development mailing list
of the Eclipse project."
<eclipse-dev@xxxxxxxxxxx>,
Please respond to eclipse-dev-bounces@xxxxxxxxxxx
"General development mailing Subject
list of the Eclipse project." Re: [eclipse-dev] Eclipse 3.3
<eclipse-dev@xxxxxxxxxxx> endgame plan
+1
RC1 was traditionally the time where we wanted to fix a number of bugs in
preparation for the first massive test pass. While we want to exercise
caution and be on the lookout for regressions, it is a bit early for
progress-impeding approvals. Let's leave those for after RC1.
Regards,
Dejan Glozic, Ph.D.
Manager, Eclipse Development 1A
D1/R0Q/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745 T/L 969-2745
Fax. 905 413-4850
Wassim
Melhem/Toronto/IB
M@IBMCA To
Sent by: "General development mailing list
eclipse-dev-bounc of the Eclipse project."
es@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
cc
05/02/2007 04:32 Subject
PM Re: [eclipse-dev] Eclipse 3.3
endgame plan
Please respond to
"General
development
mailing list of
the Eclipse
project."
<eclipse-dev@ecli
pse.org>
Either the 'Fix approval' semantics or criteria have changed significantly
from previous end game plans.
So I would like a clarification.
I feel that that a fix approval should remain the sole responsibility of
the "component lead" in RC1 and RC2,
with additional component "leads" approval(s) needed for RC3/RC4.
This was the case in all previous releases, including the awesome 3.1
release, and I am not sure why we are changing it.
http://dev.eclipse.org/viewcvs/index.cgi/eclipse-project-home/plans/3_1/freeze_plan.html?view=co
Was there a problem in this area in previous end games that we are trying
to fix with this change?
As for the 'Extra Checking' requirements, they are stricter this time
around, but that's great.
Thank you,
Wassim
Kim
Moir/Ottawa/IBM@I
BMCA To
Sent by: eclipse-dev@xxxxxxxxxxx,
eclipse-dev-bounc platform-releng-dev@xxxxxxxxxxx
es@xxxxxxxxxxx cc
Subject
05/02/2007 04:01 [eclipse-dev] Eclipse 3.3 endgame
PM plan
Please respond to
"General
development
mailing list of
the Eclipse
project."
<eclipse-dev@ecli
pse.org>
The daffodils are in bloom which means it's time for bbqs, frosty beverages
in the hammock and the Eclipse 3.3 Endgame. After M7 is released later this
week, we'll enter the final phase of the release cycle before the Europa
release.
The details are available here....
http://www.eclipse.org/eclipse/development/freeze_plan_3.3.html
You will notice that increasing levels of approval are required for
submitting code to each subsequent release candidate. For instance, for
RC1 another committer must +1 your bug report. All changes must have their
associated bug reports tagged 3.3RC1. As well, an additional committer
must check all code changes prior to release.
Kim_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
