Juno/Final Daze

Final Daze

Our ramp-up to our annual Simultaneous Release is similar to previous years, but read closely to help make sure everything goes smoothly.

The following is a "blow-by-blow" schedule of the final days leading up to the yearly simultaneous release. Following these details is one of the responsibilities of our heterogeneous projects working together towards having a simultaneous release.

Failure to follow these procedures and schedules can have dire consequences, which we all have seen before in years past -- if not done in the right way, in the right order, at the right time, mirrors get busy replicating one project, but other projects have difficulty accessing eclipse.org to produce their final builds much less upload them, so a "chain reaction" begins and everyone is much delayed simply due to network and infrastructure bottlenecks -- or, I should say, from someone not following these procedures and schedules! :)

This schedule and procedure should ensure the mirror system gets fully populated before demand for downloads gets in full swing -- meaning much fewer delays, 403's, and failed downloads for end-users -- which all Eclipse users will appreciate.

From Now to 6/20 (one week before release, which is 6/27)

Clean up "old" builds and archive releases

Delete "old" builds and milestones and archive previous releases. This is important to reduce the disk space used, not just on eclipse.org servers, but more important, the space used on the mirror servers. Not only is this a "nice" thing to always do, it is essential for the yearly Simultaneous Release, as it can help avoid those mirror servers from filling up once they get the final release and they themselves having problems mirroring the release. And, of course, if they have problems, we all have problems! Everyone should have space at, if not already using, archive.eclipse.org, and if you are not sure how to archive files, please ask (it is easy).

We ask this clean up to be finished at least one week ahead of the release so a) all mirrors can be sure to easily get "synced up" with the new minimal amounts, and b) allows time for some inspections and audits. Projects that appear to be non-compliant will be asked to explain their use of Eclipse.org resources.

Final Build 6/13 -- end of RC4

The Milestones and Release Candidate dates are defined in the Simultaneous Release Plan.

RC4 is considered final, to be followed by a quiet week reserved for final testing and final preparations for the release.

The "final build" means that all content must be frozen; features, plugins, versions, etc. This content might still have an "RC" in zip file name, be on a "temporary" site (e.g. ...<project>/milestones) and later (such as during quiet week) renamed and moved to a "permanent" site (e.g. ...<project>/repository) but during that rename and move, there should be no change to plugins, features, versions, repository metadata (artifacts.xml/jar files and content.xml/jar files). Though, there will often be changes required for the p2 metadata repository's properties. For example, when the p2 artifacts metadata (artifacts.xml/jar) is moved to its final location, be sure its mirrorsURL is updated to reflect the new location of the artifacts (see "how to enable mirrors"). Some projects also may also have a version-specific p2.statsURI property that needs to be updated. (See p2 download stats).

From 6/18 to 6/22 -- The (not entirely) Quiet Week

Finish final testing

Projects will have normally finished all basic testing by now, but, still, quiet week is a good time for committers and adopters to do more testing. At this point, while it is too late to fix a bug and rebuild, it is always best to know about a bad bug or regression before users run into it. In some cases, if the bug was bad enough, a project may want to prepare a "patch" or workaround instructions before the release. Normally, discovering a "bad bug" during quiet week would not be justification to rebuild the common repository and EPP packages. Normally, the only reason for any rebuilds during quiet week would be if there was a bug that affects installation or update itself, or one project prevented another project's code from working, or there were some IP irregularities requiring removal of some project's files or bundles.

Finish Juno Info Center

Provide documentation bundles locations (for copying) in bug 379598.

Prepare releases (renames, etc.) off-line

There is no need to wait until "the day before release" for projects to put their artifacts in their final location, but they must remain "invisible" until the official release day. It is actually important and encouraged for most projects to get artifacts into position "early", during quiet week instead of the "day before release" so that mirrors can get caught up. If everyone promoted on the one day before release, it means the mirrors are very busy pulling content the day before, and have trouble getting caught up and in a steady state before the actual release. (From casual observation, it takes roughly 4 to 7 days for all mirrors to get in sync, though a few are within half a day, and a fair number are within one day).

During quiet week, prepare your final releases zipped files, repository sites, etc., but only put zipped up builds, update jars, etc., in their final (mirrored) release areas of eclipse.org if you leave them "invisible". If you do not know how to leave them invisible, please see the "how to make invisible" FAQ or ask for clarification on cross-project list. If you have a special circumstance that does not fit in the normal procedures and schedule, please send a note to cross-project list or discuss with our Eclipse Webmasters (Denis or Matt) at webmaster@eclipse.org and work out a plan to accommodate your special situation.

Projects must ensure their repository sites and *.b3aggrcon files stay coordinated, so the common site can be re-created on a moment's notice, if required.

If you do need some official, final release URL of a pre-req project (such as to update your final release pages, please work with them to find out what it is ... since it will not be "visible" through the normal channels.

Note: we do not have formal "sign off" pages, so it is critical that if anyone is the least bit late (or even close to being late) to meeting a deadline, please keep everyone informed via cross-project mailing list.

Tip: When you copy/push your final content, do not use -t in your rsync commands, but let the file time take on the current time that the copy was done ... the reason is that the mirroring system uses timestamps to infer what's been mirrored and what has not, and a file that appears "old" may end up being assumed mirrored already, when in fact has not been mirrored yet ... which will result in users getting 404s from mirror site URLs.

Common repository site and EPP preparation 6/18 to 6/22

It is assumed "staging" content is complete and final EPP packages prepared by the end of RC4. There may need to be some adjustments needed during quiet week to some of the composite repository files so they point to the final location of EPP repository or, some years, the final location of the Eclipse Platform repository.

The RC4 "staging" repo is not promoted to /releases/juno like usual at the end of RC4 (or, else, we would be "releasing" early).

The common repository and the EPP packages, though, will be moved to their "invisible" locations, so they can have plenty of time to propagate to mirrors.

Remember to check that artifact repositories have correct "mirrorsURL".

Monday 6/25

By end-of-day (5 PM Eastern) all projects should be "done", having prepared content, at final locations, even though still "invisible" to normal web browsing and p2 installers.

Monday is the last opportunity for anyone to declare "emergency, stop ship" (and it had really better be an emergency)!

Tuesday 6/26

By 10:00am EDT

• copy EPP packages to their final location /technology/epp/downloads/releases/juno/ if not yet done at the end of the Quiet Week <== this is super important, as the Main Downloads Page and the Packaging Site makes the EPP packages the default!

[Markus] Check availability of the package archives, file names, checksum files, XML configurations for the web site

[Chris] Disable the Cron job from updating the Packaging Site Till 9AM Wednesday

• Denis sends out mail to the members participating at the Member Downloads Program
• Denis prepares torrent files
• Denis sends email to eclipse-mirrors
• Chris publishes 'Juno is here for Friends only' page for the main downloads page; links for Friends mirrors and Bit Torrents only
• Denis Emails Friends of Eclipse with details on how to get the downloads from the friends mirror.

16:00

• wait overnight, make sure mirror are well populated, etc.
• projects should prepare final web pages, announcements, press releases, etc.

Wednesday 6/27

08:30 EDT

• Denis to update alias for http://help.eclipse.org to go to http://help.eclipse.org/juno
• Denis to do a mirror-site sanity checks if needed.

09:00 EDT

• Denis to announce on cross-project that Projects can now make their download pages visible.

• David to "flip switch" on common repository, making release content visible to p2, and removing any previous release candidate pointers.

• Markus to "flip switch" on trusted EPP repository /technology/epp/packages/juno - should be synchronized with the common p2 repository switch

• Chris

1. Put web pages live, make announcements.
2. Update Homepage / Promotion / Friends of Eclipse Images to post release.
3. Re-enable Packaging Site Cron Job and Promote Final Release to Front Page.

Update meta-data

These do not necessarily have to be done on the release day, but then, or shortly after.

• David updates Simultaneous_Release wiki page (such as, removed "planed", change to final URLs, etc.).

• Project Leads should update their Project meta-data at Foundation Portal, when needed, to update "complete" status, final download URLs, etc.

13:41 EDT

• Earth Shattering Kaboom - http://earthquake.usgs.gov/earthquakes/dyfi/events/us/2010xwa7/us/index.html