Re: [cross-project-issues-dev] Re-spin process

[David M Williams <david_williams@xxxxxxxxxx>]

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. 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