Now that Fedora 7 has been released, Fedora project leader Max Spevack has
a little bit of breathing room. Like nature, LWN abhors a vacuum, so we
sent Max a list of questions and a request for answers. We are now happy
to present the answers. Without further ado...
LWN: Fedora 7 is out. Congratulations! What do you think is the
best single thing about this release, and what do you most wish had been
There are two "single best things" about Fedora 7. :-)
The first is the combination of Fedora Core and Fedora Extras into a
single package repository, and the other work that went into place
Before I go on, let's define two things:
@redhat.com == employed by Red Hat
@fedoraproject.org == anyone who is a Fedora contributor, may or may not
be employed by Red Hat
Pre-Fedora 7, a package maintainer had to be @redhat.com in order to
have commit access to packages that were in Core, but anyone
@fedoraproject.org could have commit access to packages that were in
Extras. Core and Extras were built on separate build systems. The Core
build system was internal to Red Hat, and the Extras build system was
completely external. The compose tool that built the install tree and
ISO was only able to pull from packages that were in Core.
Fedora 7 has blown all of that up.
The CVS has been combined. There is no more Core or Extras, just a
single Fedora repository, which allows us to give commit access (via
ACLs) to anyone @fedoraproject.org for ANY package, as appropriate. It
allows people who have expertise in specific packages to have more
direct access to those packages in Fedora, regardless of whether or not
they are @redhat.com.
Similarly, we have rolled out a new build system, called Koji, which
operates completely externally from Red Hat. Add to that a new compose
tool, called Pungi, which assembles the output of Koji into an actual
distribution, and the entire Fedora "toolchain" is now 100% in the
The end result of all of that is the second "best thing" about Fedora 7:
Pungi, as I have already mentioned, is a command-line compose tool. You
feed it a package manifest, it spits out an install tree, or an
installable CD/DVD. Similarly, LiveCD Creator is the command-line tool
that we use to build our LiveCD, LiveUSB, etc. It's quite similar to
pungi -- you feed it a package manifest, it does the rest.
Additionally, two of our most enterprising community members, Jeroen van
Meeuwen and Jonathan Steffan, have built a graphical application on top
of the Pungi and LiveCD Creator APIs. This tool is called Revisor, and
it provides a graphical wizard-like application that allows the user to
select various repositories (Fedora or third-party), and to select a
package manifest and various build targets (Live, Installable, USB,
etc). The backend of the tool does all the work, and the end user can
spin a custom version of Fedora without having to understand all of the
technical details going on underneath.
Koji, Pungi, LiveCD Creator, and Revisor are all available in the Fedora
repositories. Every tool that Fedora uses, from source control to ISO
production, is 100% free software.
On the negative side, things got a little bit crazy in the last week or
so prior to the release. A few regressions made it in, and while those
can be fixed with things like 0-day updates, it's still not a good thing
to have. So we'll work to improve that.
Also, the "feature" process around Fedora needs some fixing and
managerial oversight. We're working to correct that in Fedora 8 by
setting up a small team that is entirely focused on feature tracking,
status, etc. Basically we're giving Fedora a bit more project
management than it's had in the past.
So what can we expect for Fedora 8?
One of the things that we want to do with Fedora 8 is get the release
cycle back on a predictable track. A 6 month cycle, beginning on June
1st, puts the release date smack in the middle of Christmas.
Furthermore, the Thanksgiving holiday in the United States is something
that needs to be planned around. In short, we were worried that a 6
month cycle for Fedora 8 would very quickly slip out to 7 or 8 months
simply due to the holidays that come at the end of the year.
So we're looking to shorten the cycle up, with a Fedora 8 GA tentatively
scheduled for October 31st.
That doesn't leave us a lot of time. Fortunately, we're looking at a
far less ambitious Fedora 8. With so much new stuff in Fedora 7, we'd
like to give all of our infrastructure changes a chance to settle in and
get some polish, and also give some of the contributors who have been
going nonstop on Fedora for the last few months a development cycle that
is a bit less stressful.
But that doesn't mean we don't have some things planned. The best thing
for people who are interested in Fedora 8 to do is look at our wiki,
where we will be tracking potential features over the course of the
release cycle. Before you click that link and hold us to it, I will say
again that this is early-stage planning right now, and just because
something appears on this list today doesn't mean it will be in the
final release, or that it will even make it through the culling process
in which we decide what is *really* important and what is of secondary
One thing not on that list that I am hoping we can get on there soon is
additional improvements to the LiveCD tools -- especially the LiveUSB
key, hopefully with encryption well-integrated into it. But that's just
me talking as a manager -- the core developers still need to have a
chance to weigh in with what they are thinking, and what their time
commitments are going to be.
The second feature that I am particularly fond of is one that actually
exists independent of any sort of distribution release cycle, and that
is the expansion of Revisor from a GUI application to a web application.
A web app that allows people to create a custom Fedora spin or a Fedora
appliance will be a tremendous achievement for the Fedora Project, and
will be the capstone to all of the work that has already been done with
Koji, Pungi, LiveCD tools, and Revisor. Do I think this will be ready
near Fedora 8? Not necessarily something that is fully production
ready, but since we intend to develop it in public, hopefully at least
some sort of alpha/beta that is usable.
What can you tell us about the longer-term plan for Fedora? Where do
you think the project will be in 2-3 years?
I have to start this answer off with a statement of fact:
Red Hat will continue to be Fedora's biggest sponsor, providing
development resources, infrastructure money, bandwidth,
community-budget, FUDCons, legal support, etc.
However, I believe that it is ultimately the job of the Fedora Project
Leader, whoever that person is, to say "what do I have to do to ensure
that the Fedora Project can grow and thrive, *EVEN IF* all Red Hat
support were to one day disappear"?
It's a hypothetical question. But the answer is real. And the answer
is the critical path of Fedora in a 2-3 year horizon.
16 months ago when I started my time as Fedora Project Leader, the
critical path was the fact that Fedora's development infrastructure was
split. We've taken the steps necessary to fix that problem. Hopefully
now we can start to reap some of the rewards.
Over the next 2-3 years, I hope that we see more and more packages that
were "Core" become co-maintained by both Red Hat developers and non-Red
Hat developers. The infrastructure for this is now in place -- but the
process itself needs to mature in its own time.
I hope that we see the Fedora Project further solidify itself as an
upstream base for other distributions, not just things like Red Hat
Enterprise Linux and other RHEL-derived distros. We're already seeing
some success in this arena, as the One Laptop Per Child project is built
on the Fedora base.
Again, we believe that we've created the infrastructure for this in
Fedora 7, but it will take a year or two for the results of that to
trickle down. Hopefully we'll one day see Fedora hosting the "best of
breed" (though I hate buzzwords like that) appliances and spins for all
sorts of different use cases.
As always, a major goal of Fedora is to continue to lower the barrier to
entry for new contributors. With our technical world in decent order, I
think we'll have more time in the coming year for work like this, which
should pay dividends 2-3 years down the road. Hopefully Fedora can grow
into a project that has a much larger community of "developers" as
opposed to "packagers". We're really really good at the latter (and
that's a great thing), but I'd like us to continue to improve in the
There has been some grumbling from the ranks of (former) Fedora Extras
maintainers that the new update process just adds bureaucracy to their
job. Has anything been done to make those maintainers happier?
The short answer to this question is that things are a bit rough right
now, but folks (the Fedora Engineering Steering Committee, comprised of
both RH and non-RH contributors) are actively working on making things
better. Time just ran out to have it all done pre-F7.
We are working on both streamlining the updates process through command
line submission tools that can be scripted, and also revamping the ACL
process to use the new package database that has been built.
In the past, there was a difference between updates for a Core package
and an Extras package.
For Extras, you build the package and it was pushed the next time that
Extras was pushed out, without any real need for notification to users
about what the update was, etc.
For Core packages, you built the package, filled out a template in a
web-based updates system, and then went through updates-testing and
finally to the updates repo with a announcement and visible change
information coming from the yum applet.
The Fedora 7 workflow, right now, feels a lot like that old Fedora Core
workflow. However, our new updates infrastructure, Bodhi, is being
rolled out, and we believe that will help the situation.
What the updates workflow is GOING to look like is:
- Build a package, and send information to Bodhi about the update either
through a web form, or a command line tool that is integrated with the
- Optionally (I'm not quite sure what the criteria around this option
are, it's probably up for discussion) send the update to updates-testing
with an announcement.
- Once the developer is happy, send the update to the official updates
repo either via the web UI or the command line tool.
- Bodhi will generate an announcement email and the yum applet will have
visible change information, so that when the user gets the pop-up that
says "5 new updates are available" the user will be able to know what is
being updated and why.
So the biggest change here is that the freedom to update packages that
were once in Extras without having to really specify what those changes
were has been curtailed. And at the same time the tools are being
worked on to make the updates process as easy as possible.
Whatever happened to the proposed
developer ranking system? Is that
still something the project is considering?
It was an idea that was proposed on some Fedora mailing lists earlier
this year. It never really gained much traction beyond that. Maybe
someone will resurrect it. Maybe not. Personally I don't think this is
a critical-path topic. But that's easy for me to say, because I've
already declared myself a level 60 Fedora Ninja.
Red Hat still maintains a fairly firm control over parts of the project;
the decision to not consider outside artwork for Fedora 7 is one
example. Do you expect that to continue, or will the Fedora project
become more independent over time?
Fedora must continue to become more independent over time.
The situation with the Fedora art community and Fedora 7's art was very
unfortunate. There are some people (including me) who think that we
should allow Fedora's artwork to be created, judged, and used the same
way that we do with Fedora's code. There are others who think that
artwork is a different beast, and that for it to be done well, it has to
happen in a more "closed" environment than other parts of Fedora
I am not an artist. But I think Fedora 7's art looks great. I am also
not the sort of person who is going to base my decision of what
distribution to use on the default theme that is provided by that
distribution. That isn't to say that I don't think great artwork is a
major selling point -- I just don't think it's enough of a deal breaker
to warrant the breaking of the rules that the rest of Fedora plays by.
I believe that Fedora has a tremendously committed and tremendously
talented art community. I believe that the Fedora Project has a
responsibility to give those artists a place where they can do their
work, and see their work put to good use.
Put bluntly -- I would like to see all (not just some, but all) of the
artwork in Fedora developed openly, in the same community-oriented way
that we try to build the rest of the distribution. If such a decision
results in some short-term growing pains, I'm fine with that because I
think the long term community that will result from such a commitment
will be stronger.
The very technical goals of Fedora 7 required all of my "political
capital" so to speak, in order to make happen. I couldn't win an
additional fight about the manner in which parts of Fedora's artwork was
produced. Was the end result good? Yes. Was the process good? No.
Did I sort of have to take it on the chin? Yes.
Will I allow the same thing to happen again for Fedora 8? No. The
Fedora 8 artwork will be developed in the community, and whoever the
"lead designer" of that artwork is, it will be a requirement that that
person conduct their work with the input of Fedora's larger art
community, or the final work, no matter how beautiful it might be, will
The development process at rpm.org has been quiet for a while (though a
look at the lists shows that some things are happening). Meanwhile, the
other RPM has launched rpm5.org and appears to be headed toward a major
release. How do you feel about the state of rpm.org development, and is
there any chance of joining this fork sometime in the future?
I have to answer this question from several different angles.
First, from the "RPM.org as a self-contained engineering project that
various distros use" angle:
Right now, a maintenance release (22.214.171.124) is being prepared, with a
release planned within the next two or so weeks. Its primary goals are
bug fixes, and the review/merge of patches from vendors (mainly SUSE and
Once that maintenance release is out, the development cycle of the next
major version of RPM will begin.
Speaking with the RPM developers, my understanding is that its focus
will be on making the codebase more maintainable, cleaning up and
improving the APIs, and getting a proper and predictable
development/release process in place. This, we think, will also help to
build a more healthy community around RPM, both of developers and
The rpm.org developers have been keeping an eye on what the rpm5.org
team is doing. Both trees have some common interest areas and code. The
long-term is where the two projects differ.
On rpm5.org (http://rpm5.org/roadmap.php), it says:
"The main RPM development is already focused on the development of the
forthcoming RPM 5.0. The primary goals of RPM 5.0 are the additional
support for the XML based archiving format XAR
(http://code.google.com/p/xar/), an integrated package dependency
resolver, further improved portability and extended cross-platform
support. The final RPM 5.0 versions are expected to be released in the
second half of 2007."
In short, the rpm5.org development plans give RPM a *larger* scope. The
rpm.org development team thinks that RPM should have a *smaller* scope.
RPM should be a solid, stable foundation of a system. Everything else
should be built on top of it. Keep RPM small and extensible by
providing good and stable APIs.
Now, from the "Fedora as a distribution built around RPM" perspective:
RPM needs to grow and improve, but we need to make sure it grows in the
right direction. And like most things in the world there are different
opinions on where RPM go.
Fedora provides tools like pungi and revisor that allow someone to use a
release from rpm5.org and spin up a distribution centered around that.
If a group of Fedora users wanted to spin a version of Fedora 7 using an
rpm5.org release as a basis of comparison and testing, that would
probably be a pretty interesting activity, and I would think that the
results of it would be useful to developers working both at rpm.org and
rpm5.org. That is the simple reality of the open source software world.
The Fedora Project is committed to
using rpm.org's work as its upstream.
Many thanks to Max for taking the time to answer our questions in such
to post comments)