One of my jobs within Red Hat is help to make sure Red Hat Engineering is in sync with what Fedora is doing and vice versa.  Many people assume that because the Fedora Project is sponsored by Red Hat that it has a heavy hand in every Fedora decision.  Recently there was also a conspiracy theory on one of the mailings lists that Red Hat intentionally ignores Fedora bugs to drive people to Red Hat Enterprise Linux.  I’d like to reassure you that neither is true. 🙂

At a recent engineering meeting we talked about how the Fedora 9 release went from a Red Hat perspective. We also talked about things we thought would make Fedora 10 a better release. It was a fun meeting where each person had a few minutes to give their take on the release.  In some cases everyone agreed and in others what one person considered a success was deemed less successful by another.  All in all it was a thought provoking discussion.

I thought it might be useful to the community to share a few of the ideas that came out of this meeting (with their permission) as we think about Fedora 10.  Ideally this information will spark other ideas, garner support and continued involvement from community members on what should be considered and prioritized to make Fedora 10 our best release yet.

The items presented here have not been prioritized or ordered in any special way.

Things that were better in the Fedora 9 release cycle compared to Fedora 8?

  • Feature process
  • Detailed schedules
  • Mirroring infrastructure was solid
  • Release notes process
  • Artwork process was smoother
  • A lot more infrastructure capacity on release day
  • Help from RHEL installation team with Fedora test plan and test cases
  • New community testers
  • Adherence to packaging guidelines
  • Bug triage group revitalized
  • Very few fires on release day
  • More community folks involved with infrastructure group
  • More people working on yum and rpm
  • Getting yum 3.2.x into RHEL5 provided helpful feedback for Fedora
  • Lots of changes to kernel following upstream and greater interest from upstream developers in Fedora
  • Building release engineering team
  • Better coordination at release time through release readiness meetings and infrastructure ticketing system

What could be improved from Fedora 9 to make Fedora 10 a better release?

  • A smoother artwork process
  • Strengthen installation testing and evaluate role of rawhide
  • Engage more community members in testing
  • Better and earlier identification of blocker bugs
  • Move EPEL build system to use Koji instead of plague to make it less fragile
  • Integrate delta rpm packages
  • Better document and advertise existing install features that other distros claim as “new and exciting”
  • Capture critical or negative aspects of Fedora 9 news stories and reviews and attempt to address them
  • Reduce the manual steps required to compose a release
  • Consider test cases as part of newly proposed features
  • More stickiness with new account sign ups (mentoring, progression for volunteers)
  • An automated and secure package signing server that is fast
  • More days of “installable rawhide”
  • A larger number of community people working on the release
  • More release day coordination and verifying links in announcements
  • More automated tree validation after compose
  • Coordination with Special Interest Groups (SIGs)
  • Do a better job with Codeina
  • Collect better metrics on the release and establish clearer criteria for measuring success or failure
  • More progress with secondary architectures
  • Coordinated marketing and pre-generated stories for Digg, Slashdot, etc. in creating news storm

Nice to have things for Fedora 10 if resources and time were in unlimited supply

  • The ability for Release Engineering to “press a shiny button” to create new releases
  • Lots of testing by lots of people
  • LiveCD build process working with SELinux enabled
  • A test tracking tool more sophisticated than the current wiki
  • A perfect way to make Fedora design decisions–make sure all the right parties are involved
  • Every feature page completed 100% and updated on time without having to nag people