Jump to: navigation, search

Difference between revisions of "Callisto Coordinated Maintenance"

(The Wiki Plea)
m (What, exactly, is fixed?: fix links)
 
(16 intermediate revisions by 5 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 is in the fall (9/29/2006), and the second in the winter (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
Line 31: Line 31:
  
 
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
::8/15 most teams should have identified what they will attempt to fix for Callisto Fall Maintenance
+
:2/1 - release candidates available for testing.  
::9/15 release candidates available for testing.  
+
:2/12 - zips and update site files ready to start the mirror process
::9/27 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].
::9/29 Callisto Fall Maintenace available.
+
  
 
==== Conference calls ====
 
==== Conference calls ====
* Thursday, August 24 9am PT, noon ET
+
* <strike>Thursday, January 18 9am PT, noon ET</strike> ([[Callisto Minutes 2007.01.18|minutes]])
 
** Discuss which bugs are going to be fixed by each project and what impacts those will have on other projects
 
** 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
 
** Discuss the build process we will use including the update site
* Thursday, September 7 9am PT, noon ET
+
* Thursday, February 1 9am PT, noon ET
** Brief call to check on progress (see minutes below)
+
** Brief call to check on progress
* Thursday, September 21 9am PT, noon ET
+
* Thursday, February 8 9am PT, noon ET
 
** Slightly longer call to verify no conflicts so far
 
** Slightly longer call to verify no conflicts so far
* Thursday, September 28 9am PT, noon ET
+
* Thursday, February 15 9am PT, noon ET
** Go-no-go decision meeting
+
** 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#''
 
''    613.287.8000 or  866.362.7064 passcode 874551#''
  
Line 53: 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 63: 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.)
  
Line 74: Line 73:
 
* 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=|]
 
* 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=|]
 
* 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/]
=== Minutes From Calls ===
+
* EMFT [http://www.eclipse.org/modeling/emft/news/]
==== September 7, 2006 ====
+
Attending: Sri Doddapaneni, David Williams (also for Nick Boldt), Tim Wagner, Doug Schaefer, Kevin Haaland, Bjorn Freeman-Benson
+
Regrets: Wenfeng Li, John Graham
+
 
+
* BIRT progress is going well; 9 bugs left as of the call; good shape to finish before 9/29
+
* CDT going well; ramping down defect list on 3.2.1; code freeze next thursday
+
* DTP going well
+
* EMF ''no report''
+
* GEF ''no report''
+
* GMF ''no report''
+
* Platform doing well
+
* TPTP doing well; code freeze already happened; monday starts release candidate
+
* WTP no problems - code complete tomorrow; PMC triage 8th; code freeze on 15th
+
* VE no problems
+
 
+
Bjorn is to post the minutes to the wiki and the cross-projects mailing list.<br>
+
Bjorn to remind everyone about the next phone call
+
+
David status on process and procedures:
+
* working on instructions and procedures this week
+
* by the 15th we can have test update sites
+
* Bjorn will be trained on the mechanisms
+
+
Sri wonders when other projects are going to have their build candidates available; project should announce when their builds are available
+
+
Platform is at maintenance RC, don't plan more builds unless there are blocking issues; maybe there is one more build if a final bug is accepted for the stream.
+
+
David is concerned that all the version numbers may or may not have evolved in the correct way. People need to check this carefully once we have all the bits in the test update site.
+
  
 
=== 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)