Through a Wire Fence:
Fedora and RHEL

Paul W. Frields

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

SUMMARY

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 RHEL.next
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
problems...
...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
technology
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
lifecycle

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
form

What Went Well? #4

Quality.

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

What Went Well? #5

Openness of development plans.

One-two punch of Flock + DevConf.cz
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,
firewalld
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
advantage

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 Fedora.next and Project Atomic
may end up being critical to next RHEL
Need support from and collaboration
with community as always!

Through a Wire Fence:Fedora and RHEL