Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] Re-spin process

John said:
> 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.
>
This matches my thoughts exactly.

McQ.



                                                                           
             John                                                          
             Arthorne/Ottawa/I                                             
             BM@IBMCA                                                   To 
             Sent by:                  Cross project issues                
             cross-project-iss         <cross-project-issues-dev@eclipse.o 
             ues-dev-bounces@e         rg>                                 
             clipse.org                                                 cc 
                                                                           
                                                                   Subject 
             08/07/2007 02:43          RE: [cross-project-issues-dev]      
             PM                        Re-spin process                     
                                                                           
                                                                           
             Please respond to                                             
               Cross project                                               
                  issues                                                   
             <cross-project-is                                             
             sues-dev@eclipse.                                             
                   org>                                                    
                                                                           
                                                                           





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:                                                               To 
 cross-project-issues-dev-bounces@e         "Cross project issues"         
 clipse.org                                 <cross-project-issues-dev@ecli 
                                            pse.org>                       
                                                                        cc 
 07/08/2007 01:59 PM                                                       
                                                                   Subject 
                                            RE: [cross-project-issues-dev] 
          Please respond to                 Re-spin process                
        Cross project issues                                               
  <cross-project-issues-dev@eclipse                                        
                .org>                                                      
                                                                           
                                                                           
                                                                           
                                                                           





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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




Back to the top