[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Eclipse 3.3 endgame plan
|
John,
I think you are mixing 'fix approval' with 'extra checking requirements'.
The 'fix approval' should be a component lead thing, while the 'extra
checking requirements' should be with the person most familiar with the
code.
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 06:09 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 don't know the reason for the change, but I can offer a possible
explanation. Some components have a large number of active commiters (close
to ten for Platform UI). That creates a huge approval burden on the single
component lead, and often means that the component lead doesn't have a
chance to scrutinize each change carefully. On the other hand, there is
often another committer on the component with lots of experience in the
area of code who would be a better person to review the changes. What you
really want is a careful review/approval by the committer who knows the
affected code best, which may not always be the component lead. I guess
this 3.3 end game plan places trust on the person making the change to find
the most appropriate person to review/approve their change. With that
interpretation, I like the 3.3 end-game rules better. I think it goes
without saying that the component lead has final control over what gets
released in their component, although that's not currently spelled out in
the end game plan.
John
Wassim Melhem/Toronto/IBM@IBMCA
Sent by:
eclipse-dev-bounces@xxxxxxxxxxx To
"General development mailing
list of the Eclipse
02/05/2007 05:41 PM project."
<eclipse-dev@xxxxxxxxxxx>
cc
Please respond to
"General development mailing list Subject
of the Eclipse project." Re: [eclipse-dev] Eclipse
<eclipse-dev@xxxxxxxxxxx> 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
_______________________________________________
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
