From:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Jeff
McAffer
Sent: Thursday, July 12, 2007 10:19 PM
To: Cross project issues
Cc: 'Mylyn developer discussions'; 'Cross project issues';
eclipse.org-planning-council; epp-dev@xxxxxxxxxxx
Subject: RE: [eclipse.org-planning-council] RE:
[cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin request
I agree as
well. The release trains are value add and need to really mean something.
Projects should do what they do, release when they release, and, from
time to time, may choose to participate in a train. The release trains
are a great thing for consumers but, as Doug points our, they are not the only
way of releasing something.
Jeff
Doug
Schaefer <DSchaefer@xxxxxxx>
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
07/09/2007
01:19 PM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
To
|
"eclipse.org-planning-council"
<eclipse.org-planning-council@xxxxxxxxxxx>, "'Cross project
issues'" <cross-project-issues-dev@xxxxxxxxxxx>
|
cc
|
"'Mylyn
developer discussions'" <mylyn-dev@xxxxxxxxxxx>, epp-dev@xxxxxxxxxxx
|
Subject
|
RE:
[eclipse.org-planning-council] RE: [cross-project-issues-dev]
Re-spin process / DSDP-TM Re-spin
request
|
|
I
agree, Mik. Different projects at different stages have different needs for release
frequency. For the CDT, we would really like to stay annually to make sure the
vendors adopting the CDT have predictable quality and schedule. However, having
said that, we do get tempted to releasing more often but then we would lose the
stability that having firm yearly dates gives us.
I
think we may be losing sight of what these simultaneous releases were meant to
be. Nothing is stopping you from releasing quarterly on your own. We certainly
aren’t making these trains the only release vehicle available to
projects, just a predictable one that commercial vendors redistributing Eclipse
projects can depend on. For their benefit (being one of them ;), I’d love
to see our next step in the evolution of the trains be doing actual integration
testing between the projects. If the projects are releasing randomly, we would
never be able to achieve that.
Doug
Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
From:
eclipse.org-planning-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx]
On Behalf Of Mik Kersten
Sent: Monday, July 09, 2007 12:55 PM
To: 'eclipse.org-planning-council'; 'Cross project issues'
Cc: epp-dev@xxxxxxxxxxx; 'Mylyn developer discussions'
Subject: RE: [eclipse.org-planning-council] RE: [cross-project-issues-dev]
Re-spin process / DSDP-TM Re-spin request
Just thought of a simpler way of
stating this.
While the SDK is mature enough for
an annual release cycle, other projects can benefit the community by providing
more frequent releases. Both biannual and quarterly update schedules
overlap well with the annual release train. Since Mylyn is continuing to
evolve rapidly, we would like Europa and EPP to consider supporting quarterly
updates.
Mik
From:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Mik
Kersten
Sent: Monday, July 09, 2007 9:26 AM
To: 'Cross project issues'
Cc: 'Mylyn developer discussions'; 'eclipse.org-planning-council';
epp-dev@xxxxxxxxxxx
Subject: [eclipse.org-planning-council] RE: [cross-project-issues-dev]
Re-spin process / DSDP-TM Re-spin request
+1 for increased frequency and
figuring out how to coordinate this with EPP. Here is Mylyn's point of
view.
Since we are part of the EPP
distros it would be good to have a well-defined mechanism and process for
getting the latest and greatest to users via EPP while supporting the Ganymede
train and Europa maintenance releases. Current constraints we see:
· Platform and other core projects get adopted every 6
weeks by early adopters, but only yearly by the majority. As long as
automatic update checking is not turned on by default we cannot count on
majority users getting new versions via update sites.
· Some projects like Mylyn are evolving rapidly and ensure
that majority users are always best off using the latest.
· Many or most integrators don't want to port more than
once a year, whereas we foresee the need to make breaking API changes, i.e.
moving from 2.0 to 3.0, at some point during the Ganymede cycle.
· Maintaining more than two streams is a pain.
Here's our current idea for how to
accommodate these constraints, and I'm wondering how this fits for other
projects and Europa/Ganymede/EPP planning.
1) Support Platform 3.3 and 3.4 with a single stream for as long as
possible, branch when necessary. This means that we will be releasing the
same version for the Ganymede train and Europa updates. (We have used this
scheme the past couple of years and ended up branching around Platform M4 each
time because we are quite dependent on internals and API additions).
2) Follow the 6 week schedule but make releases available to
majority users on a quarterly basis, i.e. every other Ganymede release.
For Mylyn this would mean something like the following post-Europa
schedule:
· Week 6: Mylyn 2.1M (pushed to Mylyn update site only,
i.e. can only count on early adopters getting it)
· Week 12: Mylyn 2.1 (pushed to Europa/Ganymede/EPP sites)
· Week 18: Mylyn 2.2M
· Week 24: Mylyn 2.2
· Week 30: Mylyn 2.3M
· Week 36: Mylyn 2.3
· Week 42: Mylyn 3.0 RC0 (incorporate API changes)
· Weeks 48-52: Mylyn 3.0 (final)
Effects of this would be:
· EPP could incorporate Mylyn updates once per quarter
ensuring that the majority of users can work from the latest and greatest.
· The “2.x” releases would have the same
quality bar as Europa.
· The “2.xM” would allow us to get feedback on
UI changes from early adopters before releasing them to majority users.
· Integrators only have to port once at the end of the
cycle, at the same time that they would be moving to the 3.4 Platform.
Mik
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of John Arthorne
Sent: Monday, July 09, 2007 8:33 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin
request
Using the same update site makes sense to me. I guess the question then is how
often the staging site is migrated to the release site. Did this only happen
twice for Callisto (once in the fall and once in the winter)? Perhaps this
frequency needs to be increased to accomodate the various release rhythms of
the projects involved. The other important element in the coordinated release
is the EPP packages. I would love to see a well known place for staging the EPP
bits, so we can invite the community to grab the latest packages and
participate in testing prior to release dates.
Bjorn
Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
07/09/2007
11:17 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
To
|
Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>,
"eclipse.org-planning-council"
<eclipse.org-planning-council@xxxxxxxxxxx>
|
cc
|
|
Subject
|
Re:
[cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin
request
|
|
John,
My plan for the Europa Fall Maintenance Update Site was to use the same update
site as the Europa release - I think that's what we did for Callisto and it
makes sense for Europa as well. We'll Europa-matic build into the Europa
staging site (as we did for the major release) until we are collectively happy
with the bits and then we will upgrade those staging site bits to the release
site.
I am already doing Europa-matic builds for the maintenance release (or the
re-spin, or whatever we decide): the results are in the usual place: http://dash.eclipse.org/~bfreeman/europa/
If you think we should do something else (a separate Fall Maintenance
Update Site, separate from the release site), let's talk about that...
- Bjorn
John Arthorne wrote:
I think this debate about respins is only happening because we don't yet have
the Europa fall update site set up yet. In the absence of this, Europa
respins are the only way to get our critical fixes out there. I suggest we
create a Europa fall update site as soon as possible so we can put the Europa
June 29th release behind us.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev