[eclipse.org-planning-council] RE: [cross-project-issues-dev] Re: Re-spi

["Wenfeng Li" <wli@xxxxxxxxxxx>]

There are a lot of great points about leveraging internet style continuous update vs. package software releases.  Putting the debate aside,  I would like to get input of a solutions on the problems we have at hand with BIRT project...

 

The specific issue we have is a missing plugin dependency in a feature definition.   It prevents user from using update manager to download  BIRT thru Europa Discovery site when the user ONLY selects BIRT and click “Select Required…” .   If user selects both BIRT and DTP, he/she will not have this issue.   It was a testing hole pre-release, since we always select DTP, WTP along with BIRT.   We shall add such test case in the future..  But I suspect that we won't be able to test all the combinations of feature selections on the update site to discover all the missing dpendencies.    The request of re-spin is to add the plugin depdency in a feature so that user will get all the required plugins installed for BIRT.  

 

Thanks

 

Wenfeng

 

 

---

From: cross-project-issues-dev-bounces@xxxxxxxxxxx on behalf of Bjorn Freeman-Benson
Sent: Sun 7/8/2007 8:15 PM
To: Cross project issues; eclipse.org-planning-council
Subject: [cross-project-issues-dev] Re: Re-spin process

While not as appalled as Doug, I do agree that re-spinning brings up the question of whether the bits were truly ready for release. Of course there are always bugs (sigh), but part of the Europa-mature release process was to limit the set of those to the Fall and Winter Maintenance Releases.

At the same time,  I like John's concept of the open and closed streams.

I am appalled at the idea of re-spinning a release like this. The idea of these coordinated releases was to show off the maturity of the processes at Eclipse. Re-spin is not that.

It even makes me wonder, if you require a re-spin at this point, did you truly meet the requirements for joining Europa? I’d say no, because the only real requirement was to have your bits ready at the same time as everyone else.

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.