Through a Wire Fence:
Fedora and RHEL

Paul W. Frields

Manager, Fedora Engineering
RHEL 7 Development Coordinator
Red Hat, Inc.


What I'll cover in this session:

  • Background of RHEL development
  • What went really well
  • What didn't go as well
  • What needs to go well for
  • Open Q&A and discussion time

My Background

  • Fedora Project Leader,
    Feb 2008 - Jul 2010
  • RHEL "operational manager,"
    Jul 2010 - Apr 2011
  • RHEL development coordinator,
    Nov 2010 - Jun 2014
  • Fedora Engineering Manager,
    Nov 2013 - present

RHEL Misconception #1

RHEL is on a N-year release cycle!
  • INCORRECT. It's more complex than that.
  • Input from:
    • Market
    • Customers
    • Partners
    • Strategic considerations

RHEL Misconception #2

RHELisms are pushed into Fedora
in a massive conspiracy.

  • NOPE. In this case, it's a simpler answer.
  • Engineers have latitude to solve interesting
  • ...and bear the responsibility of bringing
    integration into Fedora and RHEL.

RHEL Misconception #3

Working on RHEL must be so much easier
than herding cats in Fedora.

  • HAHAHAHA! *wipes away tears* If only.
  • A different set of herding tools.
  • Some (not all) of the same cats.

RHEL Misconception #4

Fedora is a beta for RHEL.

  • NO, NO, NO.
  • RHEL has its own alpha and beta phases.
  • RHEL has its own integrations and patches
  • RHEL has its own release process
  • RHEL has its own test and certification programs
  • etc....

RHEL Common Conceptions

  • Red Hat engineers work upstream and
    in Fedora to develop and integrate
  • At some point, RHEL is branched away
    from Fedora
  • Additional testing and fixes applied to
    meet enterprise customer, hardware
    partner, and certification needs
  • Then of course, the very long stable

What Went Well? #1

The Feature process.

  • Provides data for Fedora Documentation,
    Marketing, Ambassadors, and users
  • Plus bonus FPL talking points!
  • Also helps with tracking early integration
    for the next RHEL
  • Continuous improvement: Fewer
    surprises for everyone

What Went Well? #2

Conversion to dist-git.

  • It's been around so long, you may have
    forgotten what things were like before
  • Easier to deal with managing changes,
    e.g. merging back and forth
  • Within Red Hat we used a policy that
    encouraged maintainers to upstream
    changes in Fedora

What Went Well? #3

Fairly predictable schedule.

  • Sure, a week here or a week there
  • Date-driven release made it easier
    to pull in changes in an integrated

What Went Well? #4


  • Fedora stability for last several releases
    has been amazing
  • Compare and contrast to Fedora 10-12
  • Release criteria, stable update policy,

What Went Well? #5

Openness of development plans.

  • One-two punch of Flock +
  • Thanks to OSAS and Red Hat Czech
  • Increasing value of these conferences
    throughout Engineering

What Went Less Well

Important note:
Almost everything went exceptionally
well between Fedora and RHEL. Within
Red Hat, this release was recognized
as the best major release ever.

The issues following are ones that
Red Hat needs to improve.

What Went Less Well? #1

Communication with EPEL.

  • Affected by Red Hat product management
    strategic and competitive concerns
  • Will discuss with next RHEL planning
    team to see how we can improve

What Went Less Well? #2

Cross marketing of new technology.

  • Red Hat needs to put more weight
    behind communicating about
    development we support
  • Examples: systemd, GNOME 3,
  • Will be important for Wayland,
    Cockpit, others in future
  • Will discuss with RHEL product
    marketing teams for next release

What Went less Well? #3

Tool upstreaming.

  • Red Hat needs to do a better job
    pushing production tooling
    into Fedora
  • Not everything is a competitive

For the Future

  • Fedora helped to successfully build
    another major RHEL release
  • The next release of RHEL may not be
    structured or designed the same way
  • Ideas like and Project Atomic
    may end up being critical to next RHEL
  • Need support from and collaboration
    with community as always!

Questions and
Open Discussion