|RE: [eclipse.org-planning-council] Minutes from the August meetingposted for your review|
Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx
09/13/2005 05:26 AM
Kevin H described the Platform 3.2 schedule and discussed the modifications that will be necessary for the train. There was a lot of discussion around the train and what it will take to coordinate and release on the same date. The overall summary is that the end game will be extended by an additional milestone and thus API Freeze will be M5 and Feature Complete will be M6/RC0. (Note that the milestone dates in 2006 are in flux and will probably be adjusted to work around EclipseCon.) M2 is September 23rd, M3 is November 4th, and M4 is December 16th.
<tyler> It’s hard to commit to be on the train and develop a plan to accommodate such without knowing when we’re supposed to arrive at the final destination (i.e., Q2’06 GA release date is too ambiguous to expect projects to align with). We are in the midst of our 4.1 release (Nov 11) and will be finalizing our plan for 4.2 (end of June 2006) in Nov/Dec. Hopefully the Eclipse Platform project will formalize an end of June 2006 GA date (and interim milestones) before then so that we have something concrete against which to plan. </tyler>
<KH> Yes end of June 2006. </KH>
Each project is assigned a "offset" number which is the number of weeks their milestone dates are offset from the Platform dates. Thus BIRT, being a +1 project, has milestone dates of M2 = Sep 30, M3 = Nov 11, M4 = Dec 23, etc. These offsets will (obviously) be reduced over the end-game until they all reach zero.
<tyler> Above you indicate BIRT is +1 project, but below indicate +2. TPTP is actually a max(EMF,BIRT)+1 project since we will be dependent on EMF and BIRT finalizing their GAs before we can. Hence, if BIRT is truly +2 as indicated below, TPTP would be +3.</tyler>
<KH> Not sure if this is a comment about the 3.2 development milestones or the shutdown sequence to GA. During development I would prefer to have as short a cycle as possible between milestone builds. I am hoping we can hold to a 2 week lag. See next section for GA shutdown</KH>
<tyler> Also, you indicate that these offsets will “be reduced over the end-game until they all reach zero.” Our view is that the offset is determined by the length of time required to execute a final test pass on the dependent GA releases. E.g., for the mid-2005 releases, TPTP depended on EMF GA which depended on EP GA. After the EP GA, EMF needed a week for their final test pass to declare GA. And thereafter, TPTP needed a week for final test pass to declare GA. So, I’m not entirely clear about how the offsets reach zero.</tyler>
<KH>Having never done this before in Eclipse there will definitely be surprises along the way. In the planning discussion we did not get into the details of how we would coordinate the final days in June. I like the idea of internally staging the final shutdown cycle and it's important for you being at the end of the dependency chain. Perhaps I am being a pessimist and assuming that there will be some "stop ship" defects that each project will have to address in the last days and weeks of June.
Using the Platform' team's conventions and dates we will have our first release candidate (RC0) around April 1'st. (I am using the April 1'st, May 15'th and June 30'th dates because the 6 week math works out better and I like the idea of having a milestone on April Fools Day). There would be matching release candidate builds from all of the other projects that align using the staging schedule that we have been practicing during the 3.2 development cycle.
Between RC0 and GA we have a number of additional release candidate builds which come out on 2 week then 1 week cycles. Near the very end we address only stop ship defects and we build these ones only as required. What I was thinking of for the coordinated release was to aim to have concurrent release candidate builds starting on May 15'th and we would all be doing our final testing and bug fixes together for the last 6 weeks and there would be mechanisms for communicating an intent to fix a defect before the code is released to give depend projects an ability to express concerns if it would impact them.
The projects participating in the release train, the milestone they expect to start synchronizing, and the offset are as follows:
Technical Director, Open Source Process and Infrastructure
|971-327-7323 (PDT, UTC-7)|
Back to the top