Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Kepler/Final Daze"

(09:00 EDT)
(09:00 EDT)
Line 115: Line 115:
 
#Re-enable Packaging Site Cron Job.
 
#Re-enable Packaging Site Cron Job.
 
#Kepler http://eclipse.org/kepler/ landing page becomes Eclipse.org homepage.  
 
#Kepler http://eclipse.org/kepler/ landing page becomes Eclipse.org homepage.  
#Roxanne: Sends a tweet about the release.
+
#Roxanne: Announcement of Kepler on social media.  
  
 
==== Update meta-data ====
 
==== Update meta-data ====

Revision as of 11:14, 24 June 2013

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

EPP RC4 is not available like usual, nor is the RC4 "staging" repo promoted to /releases/kepler like usual -- at the end of RC4 -- or, else, we would be "releasing" early.

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 webmaster@eclipse.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.

Remember, EPP RC4 is not available like usual, nor is the RC4 "staging" repo promoted to /releases/kepler 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 and or composite values, if needed.

Monday 6/24

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/25

By 10:00am EDT

  • copy EPP packages to their final location /technology/epp/downloads/releases/kepler/ 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.

16:00

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

Wednesday 6/26 (Release day)

08:30 EDT

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 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
  • Chris
  1. Downloads page:
    1. remove friends early access banner on downloads page
    2. remove Developer Builds tab
    3. replace Eclipse Juno (4.2) SR2 Packages with Eclipse Kepler (4.3)
  2. Kepler landing page:
    1. Remove "Learn more about Eclipse Kepler".
    2. Replace "Coming June 26, 2013" with "Now Available"
    3. Add the release day below the logo in a smaller front for historical purposes.
    4. Update Downloads link with http://www.eclipse.org/downloads/index.php
  3. Re-enable Packaging Site Cron Job.
  4. Kepler http://eclipse.org/kepler/ landing page becomes Eclipse.org homepage.
  5. Roxanne: Announcement of Kepler on social media.

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.

12:00 EDT

  • 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!

13:00 EDT - Ottawa Committer celebrations

Back to the top