From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Sunday, July 08, 2007 2:44
PM
To: Cross
project issues
Subject: RE:
[cross-project-issues-dev] Re-spin process
I agree with Jochen here. Not only is it no
longer a "release", but it is also no longer "coordinated"
if individual projects can contribute new contents and request an ad-hoc respin
for Europa after the release date. Any change released to a project can have an
impact on any downstream project, thus requiring testing effort across multiple
projects. It has been mentioned already, but I think the serviceability problem
cannot be understated here as well. Not only does it cause confusion when triaging
bugs in the open source community, but it will also create confusion when
companies ship products or plug-ins that claim to be based on Europa. Imagine
company X delivering a product based on the Europa release, and company Y
delivering an add-on that has been developed and tested against Europa, only to
discover that the two are incompatible due to being based on slightly different
Europa builds. One might argue that the modularity of the Eclipse architecture
prevents bug fixes in one plug-in from having downstream impact, but most of us
know from painful experience that this is often not the case.
Having
said all that, the "moving target" approach does have its uses, both
for testing and for those who want to live on the bleeding edge and are willing
to accept the associated risks. I suggest that we carefully distinguish
"open" release train streams from "closed" ones. The
streams for the Ganymede release, and the "Europa Fall Update" are
currently open. The process bar should be low for projects that want to
contribute new contents into those streams. Once a release occurs, with
all its associated testing, coordination, process and legal reviews, that
release stream should be considered "closed". I believe there should
be a very high bar for changes to the release train after the release date, or
we risk negating all the coordinated effort that goes on to make the release
happen.
John
|
"Jochen Krause"
<jkrause@xxxxxxxxxxxxxx>
Sent
by: cross-project-issues-dev-bounces@xxxxxxxxxxx
07/08/2007 01:59 PM
|
Please
respond to
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
|
|
|
To
|
"Cross project
issues" <cross-project-issues-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [cross-project-issues-dev] Re-spin
process
|
|
Europa
has been called a "coordinated release". The proposal to make it
a "moving target" is a contradiction
with "release" to me. To me a
release implies testing, and I can't imagine that
we want to put all the
testing effort into every respin that we did put
into the June 29
release. Also for the packaging project I dislike
the idea of changing
the packages once a week (once a day), no matter
if the build process is
fully automated or not.
If projects want to release updates / patches they
can use their update
sites for it. This way users can pick up the
changes as easy as from a
central europa site, but it is clear that this
comes from one project,
and is not a coordinated release. David brought up
a good point with the
legal issues with "releasing", and I
suggest that we seek clarification
with Janet.
Also from a developers point of view I am in
favour of having scheduled
releases, major and minor, and to deliver at a
fixed date. It puts a
positive pressure on me, and I can relax after the
release.
Jochen
-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of David
M Williams
Sent: Saturday, July 07, 2007 9:58 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Re-spin
process
Second, my opinions:
Personally I like the approach where Europa is a
just a name and the
content is a moving target representing the latest
and greatest versions
of the 21 projects that initially contributed
until Ganymede ships. Of
course it is harder for developers to know which
versions of a plug-in
someone was using, but the benefits for the
community seems to be pretty
high, and it also means that we regularly re-spin
putting a higher
burden on the coordinator.
I like this approach a lot - it matches well with
the ease of
distribution that the internet provides us. I'm
not clear on your
"harder for developers to know which versions
of a plug-in" because each
plug-in has a unique four part version number.
Each re-spin that
contributes new bits would provide a new four-part
version number for
those new bits. (I'm probably missing something
subtle.)
Just a reminder, "maintenance" has to
increment third field. I do not
think update will work (i.e. update) if only 4th
field only is
incremented, and, even if it did, part of the
purpose of the version
fields is so that clients can "pre-req"
certain versions or version
ranges; for clients to do that in a realistic way,
the third field needs
to be incremented.
Also, I'd suggest, it should be "an official
maintenance release" of the
project requesting the re-spin. This implies it's
been through the
proper maintenance release process (which I think
includes some legal
vetting, some testing, and ideally some cross
project testing).
Also, recall, the Europa respins would just be a
convience for those
installing for the first time ... anyone should be
able to "get updates
for currently installed features" and pickup
the exact same bits, if
they happen to already have it installed, or,
install directly from the
projects update site (which should already be
listed in the discovery
site, if everyone is setting up their features
correctly).
I personally think the focus of projects should
still be on the
coordinated maintenance releases, since that would
optimize cross
project testing/confirmation, but, for sure,
there's no reason to limit
it to only that, if blocking or critical bugs are
found.
[Gee, perhaps someone should capture the
guidelines and process on a
wiki -- how about the first project requesting a
respin? :) ]
Bjorn Freeman-Benson
<bjorn.freeman-benson@xxxxxxxxxxx>
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
07/06/2007 03:16 PM
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
Pascal (and everyone),
Good questions. Just FYI, so far the Europa bits
have not changed -
there have been requests for re-spins and
withdrawn requests and lots of
email about it, but currently the Europa-matic is
broken RED due to
MDT/EODM
<http://dash.eclipse.org/%7Ebfreeman/europa/> . Once we have a
green Europa-matic, then we have the additional
question of what do we
do with those bits - that's where your excellent
questions come in...
First, let me answer a few of your questions:
Pascal Rapicault wrote:
- Are those re-spins put in place and lieu of
where the Europa bytes
were?
No, not yet; not until we (the Planning Council)
decides that is a good
idea.
If I try to download all of Europa now, what
do/should I get?
The same bits you got on June 28th.
- Are the EPP packages rebuilt and should they be?
I think that if we release new bits via the Europa
discovery site, we
should release new EPP packages with those bits.
But that's just my
opinion.
Second, my opinions:
Personally I like the approach where Europa is a
just a name and the
content is a moving target representing the latest
and greatest versions
of the 21 projects that initially contributed
until Ganymede ships. Of
course it is harder for developers to know which
versions of a plug-in
someone was using, but the benefits for the
community seems to be pretty
high, and it also means that we regularly re-spin
putting a higher
burden on the coordinator.
I like this approach a lot - it matches well with
the ease of
distribution that the internet provides us. I'm
not clear on your
"harder for developers to know which versions
of a plug-in" because each
plug-in has a unique four part version number.
Each re-spin that
contributes new bits would provide a new four-part
version number for
those new bits. (I'm probably missing something
subtle.)
As for the Europa coordinator: the overhead is
fairly low, especially if
the re-spins are not emergencies, and the overhead
for Ganymede will be
even lower. The "distribute to the
leaves" philosophy of Europa and now
Ganymede is a big help here: for Ganymede, the
Gan-omatic will do a
build, if the build fails, it will automatically
remove the offending
project and then build again; it will continue
doing this until it gets
a green build. It will notify all the project
owners by email that they
failed the build and were removed from the
Ganymede update site. Very
low overhead for me (the coordinator) because the
computer is going to
do all the work. Thomas Hallgren (Cloudsmith, Buckminster)
is going to
help me set this up.
- Bjorn
_______________________________________________
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
