Difference between revisions of "Kepler/Final Daze"
(initial draft for Kepler)
Revision as of 16:02, 1 June 2013
- 1 Final Daze
- 1.1 From Now to 6/19 (one week before release, which is Wednesday, 6/26)
- 1.2 Final common repo build 6/12 (EPP 6/13) -- end of RC4
- 1.3 From 6/17 to 6/21 -- The (not entirely) Quiet Week
- 1.4 Monday 6/24
- 1.5 Tuesday 6/26
- 1.6 Wednesday 6/26 (Release day)
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 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, 404's, and failed downloads for end-users -- which all Eclipse users will appreciate.
From Now to 6/19 (one week before release, which is Wednesday, 6/26)
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 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! Every project 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). Having the files on 'archives' allows seldom downloaded files to be retained forever without being mirrored (and, if not obvious, no need to mirror, since seldom downloaded).
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) it 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 common repo build 6/12 (EPP 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, or 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 property 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/17 to 6/21 -- 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 or release irregularities requiring removal of some project's files or bundles.
Finish Info Center
Provide documentation bundles locations (for copying) in bug 408828.
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 have a number of days to 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 updated 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 firstname.lastname@example.org and work out a plan to accommodate your special situation.
Projects should 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 specific 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.
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" property.
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)!
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 untill 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 'Kepler 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.
- wait overnight, make sure mirror are well populated, etc.
- projects should prepare final web pages, announcements, press releases, etc.
Wednesday 6/26 (Release day)
- Denis to update alias for default http://help.eclipse.org to go to http://help.eclipse.org/juno
- Denis to do a mirror-site sanity checks if needed.
- Denis to announce on cross-project that Projects can now make their download pages visible.
- David to "flip switch" on common repository, making final release content visible to p2.
- Markus to "flip switch" on trusted EPP repository /technology/epp/packages/kepler - should be synchronized with the common p2 repository switch
- Put web pages live, make announcements.
- Update Homepage / Promotion / Friends of Eclipse Images to post release.
- Re-enable Packaging Site Cron Job and Promote Final Release to Front Page.
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.
- Earth Shattering Kaboom - Wait a bit to see if issues. Make sure your pages are visible, can perform downloads and updates ... report issues to Denis :) ... but otherwise, celebrate!