Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Eclipse 3.3 endgame plan

I just talked to McQ regarding the plan.

This is what he said...
-Component leads can make rules more strict as they see fit. If a component lead sees the need to have all work approved by them for RC1, they are free to do so.  However, if some cases it doesn't make sense to have a component lead approve all work when they have ten committers (a lot of overhead). Also, this is an issue for for committers that have a component lead in a distant timezone.
-The plan is a draft.  If we find out that people are applying unstable fixes in RC1, the rules will be adjusted for RC2.
-If you have other issues with the plan, please open a bug against the PMC with suggestions for improvement.

Kim




Wassim Melhem/Toronto/IBM@IBMCA
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

05/02/2007 06:12 PM

Please respond to
"General development mailing list of the Eclipse project."        <eclipse-dev@xxxxxxxxxxx>
To
"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
cc
Subject
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


_______________________________________________
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

Back to the top