[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [eclipse.org-planning-council] Minutes from the August meetingposted for your review
|
Added comments <KH >
"Thessin, Tyler"
<tyler.thessin@xxxxxxxxx>
Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx
09/13/2005 05:26 AM
Please respond to
"eclipse.org-planning-council" |
|
To
| <eclipse.org-planning-council@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [eclipse.org-planning-council]
Minutes from the August meetingposted
for your review |
|
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>
<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.
</KH>
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>
<KH> My recollection
was there was agreement in the concept of having coordinated development
milestones and making it easier for our community to consume these builds.
We identified a range of dates that had the earliest possible date for
staged milestone builds at the beginning of November and the last possible
date to start creating staged milestones in Feb '06 (ie. if we can't
get staged builds worked out by Feb there is no chance for a coordinated
June GA). Projects like WTP and TPTP were not able to commit at the
meeting to being able to do this on a 3.2 stream this fall as they already
had release commitments. </KH>
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.
--
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council