Bjorn, some questions below. --tyler
Release
Train
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>
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>
<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>
The projects participating in the release train, the
milestone they expect to start synchronizing, and the offset are as follows:
Note that participation in this initial train is limited -
not everyone who wants to join will be able to join this year. Assuming
success, the process will be opened to additional projects next year. Also note
that if a project falls behind the train schedule, it will be dropped - we will
not slip the train. A third note: any project that has not synchronized by M5
is off the train for this year.
<tyler> I’m still not clear about what
projects get from “being on the train” (vs. simply coordinating
their releases with the Eclipse Platform, i.e., arriving at the station at the
same time on another train J). I thought there was some discussion about packaging
releases together at each milestone/release, which would provide some benefit,
but I’m not sure if that is really envisioned and I didn’t see
anything to that effect articulated in the minutes. I know our intent is
to align with the Eclipse Platform milestones to best enable consumers of our
project, but I’m not clear in my understanding of the ability to “join
the train” and the impact of “falling off the train” (is that
like falling off the wagon? J). </tyler>
Development Process Guidelines
- The Guidelines
should be clear that this is the only document that you need to read
- that this document includes all the relevant details from the
Development Process. Currently the Guidelines are not comprehensive, but
they should be because otherwise it is too much hassle for the developers
to figure out what to read.
<tyler> Is this statement (“the only
document that you need to read”) in conflict with projects defining their
respective more detailed development process guidelines? In reality, Committers/Developers
would need to read the Eclipse Development Process Guidelines for the
high-level and the Project Development Process Guidelines for the
project-specific (although Eclipse conforming) guidelines. While I agree
the Eclipse level guidelines could benefit from some further clarity, I thought
we agree that the projects would continue to retain some latitude therein?
</tyler>
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Bjorn Freeman-Benson
Sent: Sunday, September 11, 2005
1:15 AM
To:
eclipse.org-planning-council@xxxxxxxxxxx
Subject:
[eclipse.org-planning-council] Minutes from the August meetingposted for your
review
Planning Council Members,
I put the minutes from the Boston
(August) Planning Council meeting at this URL:
http://www.eclipse.org/org/councils/20050823PCMinutes.html
Please send me any corrections. In the absence of replies, I will post
them publically (i.e., link them from the councils web page) on Tuesday the
20th.
--
