Fedora Schedule Change

• What's changing?
  • Lengthen the Fedora development/test cycle, while keeping the release cycle the same.
  • Current cycle: [diagram needed]
    • 4-month merge window
      • 2 months
      • Alpha Milestone (Feature pages complete)
      • 2 months
      • Beta Milestone (All Features complete and testable)
    • 2-month feature freeze
      • 1 month
      • Preview Milestone (Any incomplete Features get dropped)
      • 1 month freeze (only blocker fixes taken)
    • Branch new Rawhide
    • Final Release
  • New cycle: [diagram needed]
    • 4-month merge window
      • 2 months
      • Feature pages complete
      • 2 months
      • Alpha Milestone (All Features complete and testable)
    • 2-month feature freeze
      • 1 month
      • Incomplete Features get dropped
      • 1 month freeze (only blocker fixes taken)
      • Beta Milestone
    • Branch new Rawhide
    • 2-month Beta period
      • Bugfixes go through Bodhi
    • Final Release

• Why?
  • Release an Alpha that actually has all the intended features
    • Our Alphas rarely have even *half* of the features ready. It's a waste of effort.
  • Give QA more time to test
    • Minus time for late features, lead time on mirror syncing, lag time on bug reporting/fixing with worldwide developers, etc. the effective QA time from Feature-complete to Final is ~4 weeks.
      • This sucks bad.
      • We have never finished the intended test plan before release.
      • A lot of the bugs we find in the first 2 months of a release are things we just didn't ever test, because we didn't have time.
  • Give developers more time to backport bugfixes from Rawhide
    • Currently: When Rawhide branches you can work on the New Hotness, but there's a massive crush of new users on the Old Code
      • And they all need their fixes RIGHT NOW
    • New Plan: When Rawhide branches, there isn't the *massive* crush of users, but all the testers will be there
      • Work on the New Hotness while the testers do their thing
      • Work on (or backport) bug fixes sometime before the beta ends.

• What's not changing?
  • Release schedule
    • Release every 6 months, on May 1 and Oct. 31
  • Development streams
    • Always one (and only one) active Rawhide.
  • Number of milestones
    • Alpha, Beta, Preview, Release

• But what about...?
  • People can already branch at Beta, and nobody does.
    • That's because those builds don't go anywhere useful - like, say, the new Rawhide tree.
  • More work for the "Build everything for all branches" crew.
    • Technically we already have 4 pipelines going (even though they only overlap by a month)
    • It would be good if we had some shortcuts for these people. It's definitely a PITA.
  • This doesn't solve the problem where everything crash-lands right before feature freeze.
    • No, it doesn't. Not directly.
    • But it does give us another 3 months to sort it out.
  • This doesn't solve the problem of wacky updates that break things.
    • No, it doesn't. Not directly.
    • That's a different - but closely related - problem.
  • This means a lot more stuff going through Bodhi.
    • Update rate seems fairly steady for the first ~6mo of a release
    • Delaying GA gives us time to find the obvious (but not critical) problems, thus spreading some of those updates out.
    • Thus we shouldn't actually have more Bodhi load.
  • Having two concurrent development streams - Rawhide and Beta is too much work for developers.
    • It's the same amount of work as having Rawhide and (New Release), but with less users (and more QA people)
      • Less bug reports - and better quality
  • Do the merge windows still line up with GNOME/KDE/Xorg/etc?
    • Xorg/glibc releases are aligned with Fedora, so that's fine
    • FIXME: GNOME, Firefox, etc?

• OK, it's worth trying. What's the proposed schedule?
  • FIXME: finalize proposed schedule

• How can we be sure it's working?
  • FIXME: suggested metrics

• What do we do if it's not working?
  • FIXME: contingency plan