Re: [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin request

[Markus Knauer <mknauer@xxxxxxxxxxxxxx>]

Hi *,

first of all: I am a bit astonished and anxious about the direction of this 
discussion. All that leaves behind the impression that many projects were not 
yet ready for a release and that there is a lack of integration/system 
testing at Eclipse???

As far as EPP is concerned, I think John's recommendations are the best and I 
would go for that. I don't want to touch the June 29th release, but I support 
the idea of starting soon with new package builds for the 'Europa Fall 
Update'. Hopefully this leads to more and better package testing and should 
improve the overall quality of the packages.

Maybe we should discuss to have more than the planned 3 EPP updates every year 
(Europa, Europa Fall, Europa Spring); as you can see on the EPP webpages  
there is currently no plan for 'past-Europa' - I intended to start now with 
the planning based on our experience from the Europa Release. But in any 
case 'more than 3 EPP releases every year' doesn't mean weekly or even daily 
EPP builds for end users.

[ EPP and the current re-spin requests: DSDP is not yet included in the 
packages, Datatools might be an issue in the JEE package. ]

Markus

On Monday 09 July 2007 17:12, John Arthorne wrote:
> Why are those criteria not met by releasing your fixes into a "Europa Fall
> Update" update site/stream? There would still be a place for the community
> and products to obtain the latest and greatest from each of the Europa
> projects, without touching the official June 29th release. I really think
> these Europa respins directly contradict the claim that we are reliable
> and that we ship on time.
>
> I understand the pain of discovering major bugs after a release date - we
> all care deeply about releasing quality code. Sadly there is *always* one
> more bug that we want to fix, and without fixing a release date there
> would be no end to the release cycle. There have already been about 30 bug
> fixes in the Eclipse top level project 3.3.1 stream, including one
> critical and three major bugs. Does this mean we should also release these
> into the respin? No, because just as there is always one more bug to fix,
> there is also always the next release. As long as there is some way to
> make the fixes available to those who absolutely need it, there is no need
> to slip the entire release.
>
> 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.
>
> John
>
>
>
>
> "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
> 07/09/2007 09:42 AM
> 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
>
> Subject
> [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin request
>
>
>
>
>
>
> Hi all,
>
> Regarding the re-spin process, I think we should recall what's the
> objective and value proposition of Europa. I found the best definition
> in the recent Planning Council Meeting Notes [1] (applied to Ganymede in
> that context):
>
>      "A reliable release stream for commercial product planning."
>
> Europa is about showing that commercial products can rely on Eclipse,
> that we ship quality and we ship it in time, and that the various
> projects can be used together because they are released simultaneously.
> In addition to that prime objective, I think there is a second value
> proposition:
>
>      "Make it simple to get an initial install of (n) dependent
> projects."
>
> This second value is more for the Open Source user community than the
> commercial one, and it's partly addressed by the EPP packages but not
> all projects are in EPP so some of them need the Europa update site.
>
> Keeping these two goals in mind, I agree that the main Europa Stream
> should be "closed" because otherwise it would not be reliable. However,
> we know that in every released product there can be emergencies, patches
> etc. -- but typically these are kept to the absolute minimum, they are
> reproducable and versioned.
>
> I consider the discussion about Europa re-spins like an extension of the
> written Ramp Down Policies that were a requirement for all projects.
> Extending what most projects wrote down, I think a re-spin of Europa
> would require "Change Review by more than one PMC for appropriateness
> and risk" before a patch can be released.
>
> Based on these thoughts, I think the requirements for an Europa re-spin
> should be
>
>    1. Reproducable: Europa on Day X must also be creatable by getting
>       Europa Jun.29 plus some documented project patches via the project
>       update sites or download sites.
>
>    2. Documented: Europa on Day X must exactly document each and every
>       change compared to Europa Jun.29 -- by listing Bugzilla's fixed
>       and listing project patches integrated (on the download page).
>
>    3. Quality: Europa on Day X must not introduce any new bugs compared
>       to Europa Jun.29 -- every patch applied must be reviewed and
> tested
>       for appropriateness and risk (by more than one PMC, I'd think,
>       extending the current written Ramp-down policies).
>
> All that being said, I have a concrete request for a re-spin: DSDP-TM
> discovered two critical bugs (192741 and 194204), which could lead to
> loss of data, just a little too late in the testing. These bugs were
> immediately announced in the release notes, but it took until after 2.0
> before a fix was available. We considered it our responsibility to
> provide a patch release (TM 2.0.0.1), which was delivered on our project
> update site as well as our download site this Friday [2]. The patch
> release was thoroughly tested; the fixes are documented on bugzilla,
> release notes, our Wiki as well as the patch build notes.
>
> Referring to what Dave said, I tested and verified that "Check For
> Updates" does work properly although only the Qualifier was changed in
> the updated features and plugins (TM 2.0.0.1 is patch-only branch and
> different than TM 2.0.1 which we'll be working on for the Fall
> Maintenance Release).
>
> Why do I think this patch release should go into an Europa re-spin? -
> Because every day, people are getting fresh bits from Europa and perhaps
> not all of them "Check for Updates" after downloading. I'd like to keep
> them from losing data and thus push the patch into Europa, just like I
> changed all the download links on our home page [3]. At any rate,
> features-dsdp-tm.xml has been updated so the next Europa re-spin should
> pick up the changes.
>
> [1] http://www.eclipse.org/org/councils/20070620PCMinutes.php
> [2]
> http://tmober.blogspot.com/2007/07/dsdp-tm-rse-2001-critical-patch-relea
> se.html
> [3] http://www.eclipse.org/dsdp/tm/
>
> Thanks,
> --
> Martin Oberhuber
> Wind River Systems, Inc.
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm