Jump to: navigation, search

Difference between revisions of "Callisto Coordinated Maintenance"

m (add emf release notes)
m (forgot UML2 isn't in Callisto)
Line 75: Line 75:
* 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/emf/news/]
* EMF [http://www.eclipse.org/emf/news/]
* UML2 [http://www.eclipse.org/uml2/news/]
* EMFT [http://www.eclipse.org/emft/news/]
* EMFT [http://www.eclipse.org/emft/news/]

Revision as of 22:39, 10 September 2006


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).

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.


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

8/15 most teams should have identified what they will attempt to fix for Callisto Fall Maintenance
9/15 release candidates available for testing.
9/27 zips and update site files ready to start the mirror process
9/29 Callisto Fall Maintenace available.

Conference calls

  • Thursday, August 24 9am PT, noon ET
    • 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, September 7 9am PT, noon ET
    • Brief call to check on progress (see minutes below)
  • Thursday, September 21 9am PT, noon ET
    • Slightly longer call to verify no conflicts so far
  • Thursday, September 28 9am PT, noon ET
    • Go-no-go decision meeting

613.287.8000 or 866.362.7064 passcode 874551#


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 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.
    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 every 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

Minutes From Calls

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.
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

As always, please feel 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)