From Fedora Project Wiki

Release Day Planning


  • Kickoff meeting: 2008-03-19, 1700 UTC
  • Attendees: PaulFrields, RickyZhou (day1), DimitrisGlezos (day1), JonathanRoberts (day1), JeremyKatz (day1), WillWoods (day1), KarstenWade (day1), JohnPoelstra, MairinDuffy, SethVidal, JonathanRoberts (day1), JesseKeating


  • Make our release day activity a little less frenetic
  • Making sure our websites/artwork/marketing/translations match up properly
  • Use lessons learned from F8, and put F9's somewhere we can find them for F10


  • How much time do we want to allocate for this meeting? (bad assumption: 60 min - we may need 90)
  • What *didn't* go well in F8 that we can fix?
  • How much of the braindump below should we include in Poelstra's schedule?
  • Can we assign action items so these things don't depend on nebulous "we" or "someone"? (The action item could be "find someone and post the assignment.")
  • Is a followup meeting necessary and if so when?


Artwork (MairinDuffy)

  • F9 art for distro
  • F9 themed banners
  • With the high traffic at this time, it'd be really nice to have a

"Join Fedora" banner :) (Do we have one already?)

  • Let's try to have this localized. An SVG is localizable, and the template

can allow translators to "translate" the filename that is shown.

  • That's a great idea. I think I have the skill to do a Makefile that will allow a normal po/ directory, and "make banners" to create the PNG files from the SVG source and the PO files.
  • Sounds like Ricky thinks this may be easy to work via puppet, just install a little bit of stuff for svg->png conversion and people can translate the same way

Documentation (KarstenWade)

  • F9 relnotes, IG, DUG... others?
  • Check F9 static pages?
  • Big-ticket wiki pages?
  • Make sure Joining documentation is up to scratch - could maybe use an overhaul soon? This shouldn't be hard to figure out.
  • Create release announcement with Marketing, ahead of schedule for L10n - base on ReleaseOverview

- Include guidelines for local teams to write a native-language whimsical announcement

  • Update this page:
  • Would it be possible to collect a complete list of links to all of the key docs pages (in one place) that will be referred to in the release announcments? -- this is the
  • Send to Fedora to QA before release day?

Engineering (JeremyKatz, TomCallaway)

  • Need to ensure that things are well-tested and that blockers get fixed in a timely fashion
  • How do we ensure that RHEL resource needs don't hurt our ability to hit the freeze and fix blockers
  • Making sure that people are ready for influx of bugs with release
  • Try to encourage people to blog about the release (?) and what's new and cool from their perspective.
  • We should keep track of these as they appear, could definitely create some marketing from them.

Infrastructure (SethVidal, RickyZhou)

  • Infrastructure change freeze
  • Coordinate with Red Hat IS (not 100% sure what this entails)
  • Torrent setup
  • Websites
  • Verify that the bits for download are live before pushing the website live
  • Get test F9 version up at fp.o/_/, *verify download links*
  • Static release notes?
  • Coordinate with L10N to make sure that translations are complete
  • Freeze website content at least 5 days before the release (needs

collaboration with everybody to avoid last-minute changes)

  • Wiki
  • Need some strategy for the wiki, which been worse than ever these days.

Will we attempt to run it on both app1/2 again? Perhaps a rewriterule for write operations?

  • Has it really been worse than ever? Is there something you guys are doing

behind the scenes to keep it up daily again? Because the response time has been much improved the last week AFAICT, but if it's at the expense of y'all's sanity, that SUCKS.

  • The newest annoyance (which I did not notice before) is 500s on certain

actions (which may be the tradeoff that allows page views to show up faster. 500s on user creation is one of the worst.

  • Be ready to convert/rewrite high load pages to static pages
  • Release notes
  • Build this into
  • Need to make sure we have a real strategy around which of the many builds we are pointing people to and doing so in some sort of consistent fashion. Choose your own adventure leads to unsatisfied users.
  • Mirrors
  • Ensure that mirrors are ready for release
  • Monitoring
  • Make sure that everything is being monitored properly on release day

Localization (DimitrisGlezos)

  • Rel announcement: Have localized announcements ready (needs a week

preparation) and urge people to publish on local news sites, fora, etc.

  • Needs Docs team and/or Marketing team work - base on ReleaseOverview
  • Websites: Translations will arrive until day 0. Make sure they're published.
  • Docs: Make sure relnotes with >90% translations are published and linked.
  • And we'll *include* in the packaging any translations more than ~0% done.
  • Software: Translation deadline is 2008-04-07. Make sure Fedora-upstream developers

repackage between this date and the one RelEng will take the packages.

  • Localized spins?

Marketing (JonathanRoberts)

  • Create release announcement with Docs, ahead of schedule for L10n - base on


  • Submit release announcements to news sites?
  • When submitting to news sites, it'd be good to have a single canonical

(non-wiki!) announcement to link to. This is sometimes hard to control, though :(

  • ReleaseOverview should cover this - or at least first half of it
  • Including statistics about the Fedora project

1. history 1. growth 1. ~ number of users 1. ?

  • Have it ready a few days before for translations to happen. We generally

allow translators to write their own, however we need a template soonish.

  • Create a list of targeted news sites in advance?
  • Blog for
  • Press releases issued by Red Hat PR department
  • What is lead time?

Project Management (JohnPoelstra)

  • Create skeleton of next release schedule
  • always seems very popular in press articles
  • Create skeleton for feature pages and pointers to the process for next release
  • Maybe ACL ability to change this page until "next release" is under way?
  • Press watches these pages and could potentially publicize something we have no plans of doing?
  • Clear the FeatureDashboard
  • Make sure all Features are listed as 100% complete on FeatureList page
  • How about a release day IRC channel to coordinate ALL release day efforts and be transparent?
  • Does it make sense to have an "F9 Release" survey of the Fedora community
  • What went well about the release?
  • What should be different for F10
  • Biggest blockers to getting things done?
  • Change bugzilla front page announcing current release and applicable bug filing details about what the current releases are, etc.
  • Add next version number (GA version) to bugzilla
  • Run processes described here

QA (WillWoods)

I always vote for longer freezes!

  • Create CommonBugs page for new release
  • Major issues from Preview Release
  • Blocker/tracker bugs that didn't make it
  • What do we do for non-final releases?
  • Link to blocker on bugzilla? This doesn't give a clear summary of issues.
  • Link to wiki? Need infrastructure support
  • Summarize major issues and put them in announcement?

Release Engineering (JesseKeating)

  • Spins? Does this even have relevance? Decisions on what's there for release date?
  • Lead time for mirrors. Freeze -> Candidate -> Release to mirrors -> Release to world timing
  • Have to wait on export approval
  • Would like to have a longer final freeze, actually 2 weeks between preview release (Final freeze) and release candidate. Slushier freeze before RC for bugfixes, RC on is only release blocker fixes.

Red Hat IS

  • JeremyKatz: This is a big part of the process not yet represented in this group
  • Let MikeMcGrath be the gateway for this part of the discussion.
  • Poelcat also glad to help facilitate
  • Now that we're in control of the bits landing on the master sites, this may be less of a concern

Action Items

  • Notify marketing, docs about the feature landings
  • Get Involved Guide - we need information there on the release cycle and how it works.
  • DIMITRIS -- to notify l10n about schedule changes
  • PAUL -- Ask gdk and Max what our media needs are for shows, and where they're being printed -- and we want to add that to requirements for Beta, and communicate it to Artwork for their schedule
  • SETH -- Find space for storing the artwork source/print-ready versions
  • PAUL -- Follow up with Max on silkscreened USB keys
  • May need bigger media to take advantage of persistence (2, 4 GB?)
  • Could have smaller 1 GB version for lower cost
  • Sell at ~cost
  • Might be better to get them without content so they don't go stale sitting around after we've paid for pre-burning
  • PAUL -- Send notice to docs-l for writing release-announcement
  • PAUL -- arrange with infra/websites to get static version of release notes on fp.o

Other discussion points

  • Layers of responsibility -- such as when you're responsible for a messaged feature, or if a default for your package affects other parts of the distro (or general usage)
  • Avoid landing any unstable bits once we're in a freeze! In an emergency, you have to let people (releng) know.
  • Longer freeze from end of wiki content changes == more time for conversion and L10n
  • Move translation deadline earlier in process (1 week)
  • Artwork blocks on name selection -- needed maybe 3 weeks earlier from F9
  • We should do one of these for every milestone point -- Alpha, Beta, PR... maybe GA!
  • more discussion on fedora-infrastructure-list
  • Thursday -- we're flipping the bits to begin mirroring F9 Beta
  • 9:45 am EDT Tuesday -- flip master mirror bit
  • Release announcement Tuesday -- NEED:
  • Release announcement
  • Press announcement (possibly a day or two late on purpose, to give our core audience time to D/L before everyone else piles on)
  • Artwork -- after the release questions -- CAPTURED IN ACTION ITEMS
  • Printing of media not well organized
  • What printer do we use?
  • If we know by Beta time, what exact media we're printing, we can get artwork printed more efficiently
  • Storing media art on wiki -- final files for F8 were enormous. Where can we store them for posterity?