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 RHEL.next
- Open Q&A and discussion time
- 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 #1RHEL is on a N-year release cycle!
- INCORRECT. It's more complex than that.
- Input from:
- 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
RHEL Common Conceptions
- Red Hat engineers work upstream and
in Fedora to develop and integrate
- At some point, RHEL is branched away
- 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 + DevConf.cz
- Thanks to OSAS and Red Hat Czech
- Increasing value of these conferences
What Went Less Well
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
- Red Hat needs to do a better job
- 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 Fedora.next and Project Atomic
may end up being critical to next RHEL
- Need support from and collaboration
with community as always!