Jump to: navigation, search

Difference between revisions of "Callisto Coordinated Maintenance"

(Initial draft of Callisto maintenance plan)
 
m (What, exactly, is fixed?: fix links)
 
(26 intermediate revisions by 11 users not shown)
Line 3: Line 3:
 
The 10 Callisto Projects have agreed to do two coordinated maintenance releases.  
 
The 10 Callisto Projects have agreed to do two coordinated maintenance releases.  
  
The first one in the fall (9/29/2006), and the second in the winder (approximately first of February, 2007).  
+
The first one was in the fall (September 29, 2006, which is fall in the Northern hemisphere, but spring in the Southern hemisphere), and the second in the winter (February 16, 2007, which is winter in the Northern hemisphere, but summer in the Southern hemisphere).  
  
 
As with the Callisto Coordinated Release, this too is a voluntary coordination of the
 
As with the Callisto Coordinated Release, this too is a voluntary coordination of the
projects involved, with as a few rules, policies, and procedures as possible. Leaving each
+
projects involved, with as few rules, policies, and procedures as possible, leaving each
project to release their own maintenance when ever they need or want to (can you believe
+
project to release their own maintenance whenever they need or want to (can you believe
there has been three already!) but, Callisto maintenance will offer a predictable time and
+
there have been three already!). But Callisto maintenance will offer a predictable time and
place that all will up to date.
+
place when all will be up to date.
  
 
And, to emphasize, Callisto maintenance itself will not be anything "new" that users or
 
And, to emphasize, Callisto maintenance itself will not be anything "new" that users or
Line 15: Line 15:
 
9/29) that all the fixes will be available from the same place.
 
9/29) that all the fixes will be available from the same place.
  
Each project can provide maintenance when ever they like, on their own, in their own "home"
+
Each project can provide maintenance whenever they like, on their own, in their own "home"
 
update sites. If current users, after that point, "search for updates to currently installed
 
update sites. If current users, after that point, "search for updates to currently installed
 
features" then those users will get those fixes .. they do not have to wait for Callisto.
 
features" then those users will get those fixes .. they do not have to wait for Callisto.
  
What the Callisto coordination will do, is get all the teams focused on the same point in
+
What the Callisto coordination will do is get all the teams focused on the same point in
 
time to make sure they get things finished up, and well tested (with other Callisto
 
time to make sure they get things finished up, and well tested (with other Callisto
projects) on the same schedule. Then, during the final daze of maintenance, we will
+
projects) on the same schedule. Then, during the final days (or daze, as the case may be)
 +
of maintenance, we will
 
put all the maintenance on the Callisto site. The biggest advantage to having the common
 
put all the maintenance on the Callisto site. The biggest advantage to having the common
update site at that point, is so that if new users come to the site, they will easily get
+
update site at that point is so that if new users come to the site, they will easily get
 
the latest versions. Otherwise, they'd install once, then "search for updates to currently
 
the latest versions. Otherwise, they'd install once, then "search for updates to currently
 
installed features" to get all the latest versions. Much easier to install once.
 
installed features" to get all the latest versions. Much easier to install once.
 
  
 
=== When? ===
 
=== When? ===
  
 
As for the planned schedule, here's a rough, proposed one:  
 
As for the planned schedule, here's a rough, proposed one:  
 +
:1/5 - most teams should have identified what they will attempt to fix for Callisto Winter Maintenance
 +
:2/1 - release candidates available for testing.
 +
:2/12 - zips and update site files ready to start the mirror process
 +
:2/16 - [http://wiki.eclipse.org/index.php/Callisto_Final_Daze#Friday_2.2F16 Callisto Winter Maintenance available].
  
::8/15 most teams should have identified what they will attempt to fix for Callisto Fall Maintenance
+
==== Conference calls ====
::9/15 release candidates available for testing.  
+
* <strike>Thursday, January 18 9am PT, noon ET</strike> ([[Callisto Minutes 2007.01.18|minutes]])
::9/27 zips and update site files ready to start the mirror process
+
** Discuss which bugs are going to be fixed by each project and what impacts those will have on other projects
::9/29 Callisto Fall Maintenace available.  
+
** Discuss the build process we will use including the update site
 
+
* Thursday, February 1 9am PT, noon ET
 +
** Brief call to check on progress
 +
* Thursday, February 8 9am PT, noon ET
 +
** Slightly longer call to verify no conflicts so far
 +
* Thursday, February 15 9am PT, noon ET
 +
** Go-no-go decision meeting, followed by [http://wiki.eclipse.org/index.php/Callisto_Final_Daze#Callisto_Winter_Maintenance_Release Callisto Winter Maintenance Release]
 +
''    613.287.8000 or  866.362.7064 passcode 874551#''
  
 
=== How?  ===
 
=== How?  ===
Line 42: Line 52:
 
Besides preparing their own project update sites, as before, there are a couple of "best practices" teams will have to be careful of.  
 
Besides preparing their own project update sites, as before, there are a couple of "best practices" teams will have to be careful of.  
  
#. Plugin versions IDs should normally only update in the third (service) position if they were changed.
+
# Plugin versions IDs should normally only update in the third (service) position if they were changed.
#. Plugin versions IDs should not change at all if they did not change at all.  
+
# Plugin versions IDs should not change at all if they did not change at all.  
#. Feature version IDs should change according to its "most greatly changed" contained plugin, so if none of the contained plugins changed, then the feature version should not change either.
+
# Feature version IDs should change according to its "most greatly changed" contained plugin, so if none of the contained plugins changed, then the feature version should not change either.
#. The end-result on the update site is to have both Callisto Initial Release available and Callisto Fall Maintenace available. Normally, users will want "the latest", but, its only good practice to allow them to install (or, more likely re-install) the previous version After all, in rare cases, they may like that previous version better, for some reason. Or, want to check some behavior, etc. to report a bug.  
+
# The end-result on the update site is to have both Callisto Initial Release available and Callisto Maintenance release available. Normally, users will want "the latest", but, its only good practice to allow them to install (or, more likely re-install) the previous version After all, in rare cases, they may like that previous version better, for some reason. Or, want to check some behavior, etc. to report a bug.  
##. Note: the mechanics of doing this "multiple versions" is that teams update their feature*.xml file in Callisto build-tools by <b>adding</b> features and versions to their lists ... don't just replace the old version with the new one.  
+
## Note: the mechanics of doing this "multiple versions" is that teams update their feature*.xml file in Callisto build-tools by <b>adding</b> features and versions to their lists ... don't just replace the old version with the new one.
  
 
=== What, exactly, is fixed? ===  
 
=== What, exactly, is fixed? ===  
Line 52: Line 62:
 
What exactly is fixed in a maintenance release? Just bugs. Teams rarely add "new features" or "new
 
What exactly is fixed in a maintenance release? Just bugs. Teams rarely add "new features" or "new
 
API" to a maintenance release, but they may occasionally. Most teams are pretty conservative
 
API" to a maintenance release, but they may occasionally. Most teams are pretty conservative
about changing things, due to the every present danger of regressions. But, I'd still expect
+
about changing things, due to the ever present danger of regressions. But, I'd still expect
 
the final number to be between 500 and 1000 bugs. (Again, each project decides their own criteria and needs.)
 
the final number to be between 500 and 1000 bugs. (Again, each project decides their own criteria and needs.)
  
As examples of what will be fixed, you can take a look at the [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&product=Web+Tools&target_milestone=1.5.1+M151&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&resolution=FIXED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=|list of bugs being fixed in WTP]  
+
You can take a look at the  
in Callisto Fall Maintenance. Or, the
+
* WTP [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&product=Web+Tools&target_milestone=1.5.1+M151&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&resolution=FIXED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=| ]
[https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=Equinox&product=JDT&product=PDE&product=Platform&target_milestone=3.2.1&target_milestone=3.2.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&resolution=FIXED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=|list Eclipse Project bugs being fixed]. (Guess who's winning? :)
+
* Eclipse [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=Equinox&product=JDT&product=PDE&product=Platform&target_milestone=3.2.1&target_milestone=3.2.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&resolution=FIXED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=| ]
 
+
* BIRT [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=BIRT&product=BIRT&target_milestone=2.1.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&priority=P1&priority=P2&priority=P3&priority=P4&priority=P5&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=BIRT+-+2.1.1&field0-0-0=noop&type0-0-0=noop&value0-0-0=|]
 +
* TPTP [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=TPTP&product=TPTP&target_milestone=4.2.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&field0-0-0=noop&type0-0-0=noop&value0-0-0=|]
 +
* DTP [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=DataTools&product=Data+Tools&target_milestone=0.9.1M0&target_milestone=0.9.1M1&target_milestone=0.9.1RC0&target_milestone=0.9.1RC1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=|]
 +
* GMF [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Modeling&product=GMF&target_milestone=1.0.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=|]
 +
* VE [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=VE&target_milestone=1.2.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&resolution=FIXED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=|]
 +
* EMF [http://www.eclipse.org/modeling/emf/news/]
 +
* EMFT [http://www.eclipse.org/modeling/emft/news/]
  
 
=== The Wiki Plea ===  
 
=== The Wiki Plea ===  
  
As always, please feel to correct or add to this wiki page. Or, start a discussion on the talk page.  
+
As always, please feel free to correct or add to this wiki page. Or, start a discussion on the talk page.  
  
 
Thanks all,  
 
Thanks all,  
  
 
[[User:David williams.us.ibm.com|David williams.us.ibm.com]] 04:51, 11 August 2006 (EDT)
 
[[User:David williams.us.ibm.com|David williams.us.ibm.com]] 04:51, 11 August 2006 (EDT)
 +
 +
[[Category:Callisto]] [[Category:Coordinated]]

Latest revision as of 18:55, 13 February 2007

What?

The 10 Callisto Projects have agreed to do two coordinated maintenance releases.

The first one was in the fall (September 29, 2006, which is fall in the Northern hemisphere, but spring in the Southern hemisphere), and the second in the winter (February 16, 2007, which is winter in the Northern hemisphere, but summer in the Southern hemisphere).

As with the Callisto Coordinated Release, this too is a voluntary coordination of the projects involved, with as few rules, policies, and procedures as possible, leaving each project to release their own maintenance whenever they need or want to (can you believe there have been three already!). But Callisto maintenance will offer a predictable time and place when all will be up to date.

And, to emphasize, Callisto maintenance itself will not be anything "new" that users or adopters could not get from elsewhere ... its just that there will be a point in time (e.g. 9/29) that all the fixes will be available from the same place.

Each project can provide maintenance whenever they like, on their own, in their own "home" update sites. If current users, after that point, "search for updates to currently installed features" then those users will get those fixes .. they do not have to wait for Callisto.

What the Callisto coordination will do is get all the teams focused on the same point in time to make sure they get things finished up, and well tested (with other Callisto projects) on the same schedule. Then, during the final days (or daze, as the case may be) of maintenance, we will put all the maintenance on the Callisto site. The biggest advantage to having the common update site at that point is so that if new users come to the site, they will easily get the latest versions. Otherwise, they'd install once, then "search for updates to currently installed features" to get all the latest versions. Much easier to install once.

When?

As for the planned schedule, here's a rough, proposed one:

1/5 - most teams should have identified what they will attempt to fix for Callisto Winter Maintenance
2/1 - release candidates available for testing.
2/12 - zips and update site files ready to start the mirror process
2/16 - Callisto Winter Maintenance available.

Conference calls

  • Thursday, January 18 9am PT, noon ET (minutes)
    • Discuss which bugs are going to be fixed by each project and what impacts those will have on other projects
    • Discuss the build process we will use including the update site
  • Thursday, February 1 9am PT, noon ET
    • Brief call to check on progress
  • Thursday, February 8 9am PT, noon ET
    • Slightly longer call to verify no conflicts so far
  • Thursday, February 15 9am PT, noon ET

613.287.8000 or 866.362.7064 passcode 874551#

How?

Besides preparing their own project update sites, as before, there are a couple of "best practices" teams will have to be careful of.

  1. Plugin versions IDs should normally only update in the third (service) position if they were changed.
  2. Plugin versions IDs should not change at all if they did not change at all.
  3. Feature version IDs should change according to its "most greatly changed" contained plugin, so if none of the contained plugins changed, then the feature version should not change either.
  4. The end-result on the update site is to have both Callisto Initial Release available and Callisto Maintenance release available. Normally, users will want "the latest", but, its only good practice to allow them to install (or, more likely re-install) the previous version After all, in rare cases, they may like that previous version better, for some reason. Or, want to check some behavior, etc. to report a bug.
    1. Note: the mechanics of doing this "multiple versions" is that teams update their feature*.xml file in Callisto build-tools by adding features and versions to their lists ... don't just replace the old version with the new one.

What, exactly, is fixed?

What exactly is fixed in a maintenance release? Just bugs. Teams rarely add "new features" or "new API" to a maintenance release, but they may occasionally. Most teams are pretty conservative about changing things, due to the ever present danger of regressions. But, I'd still expect the final number to be between 500 and 1000 bugs. (Again, each project decides their own criteria and needs.)

You can take a look at the

The Wiki Plea

As always, please feel free to correct or add to this wiki page. Or, start a discussion on the talk page.

Thanks all,

David williams.us.ibm.com 04:51, 11 August 2006 (EDT)