An interview with Fedora leader Max Spevack

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 around that.

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 community.

The end result of all of that is the second "best thing" about Fedora 7: custom spins.

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.

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.

http://fedoraproject.org/wiki/Releases/8/Schedule

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 importance.

http://fedoraproject.org/wiki/Releases/8/FeatureList

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.

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 former.

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 makefile.

• 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.

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.

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 development.

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 be unacceptable.

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 (4.4.2.1) 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 Red Hat).

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 testers.

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.