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

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

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