Fedora: looking forward [LWN.net]

May 21, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

With the final release of Fedora Core 2 out the door, and on schedule no less, now might be a good time to take stock of the project and where it's going. Unfortunately, that's not as clear as one might hope.

It's easy to see where the project is now, but the future is a bit more murky -- at least for those outside the project. For the most part, the Fedora Project seems to be meeting its goals. A quick glance at the objectives for Fedora Core shows that the project is meeting nearly all of its objectives. Fedora Core 2 contains a wide range of open source packages on the "leading edge" of development. The project has done well at sticking to release schedules, and at putting together a fine Linux distribution that more or less picks up where Red Hat Linux left off.

What Fedora has not yet achieved, however, is a significant level of community involvement beyond simple testing of releases. The situation has not been helped by the project's recent change in leadership; Cristian Gafton assumed the position of Technical Lead in January, but some have complained about a lack of communication from Gafton about the project. A quick search of the Fedora devel archives gives some credence to this complaint: Gafton has only posted twelve messages to the Fedora devel lists since he assumed the Technical Lead position -- six in January, and six in May.

We contacted Gafton to see if we could get a glimpse at the roadmap and find out whether the community will have an opportunity to become more involved in the development of Fedora Core 3 (FC3) and future releases. Here's what we learned.

LWN: How long will FC1 remain "supported" now that FC2 is being released?

Our current plans are calling for issuing security updates for FC1 for two-three months after Fedora Core 2 has been released. Realistically, once the Fedora Core 3 test1 is out (or shortly after) I would expect the development interest in the Fedora Core 1 to diminish and we will take a formal look at declaring the End of Life for Fedora Core 1.

LWN: It looks like the project managed to stick to the schedule set for FC2 pretty well. In retrospect, was the schedule too aggressive or just right? Will the schedule for FC3 be as aggressive as this one? Any breathing room between FC2 and starting FC3?

We're all very happy with the fact that we have not run into any major issues in our quest to incorporate the features we have planned for the Fedora Core 2. Of course, the desire for more development time will always be there, but I think that we have managed to put together a very good schedule and we have managed to stick successfully to it. This is one of those times where we come to appreciate the Red Hat developers' experience and leadership in planning and managing an OS release, as well as the resourcefullness demonstrated by Fedora development community.

LWN: Speaking of FC3, what can we expect to see in the next release? Do you have a clear picture of what the next release will include?

We will start having a public debate about what we will plan for FC3 pretty shortly. As far as I am concerned, I will pay attention to the deployment, testing and migration to the new GCC 3.4 SSE compiler base, further refining of the SELinux techonlogy, and - of course - the new versions of Gnome, Evolution, KDE that are planned for release in the next few months. As of right now we have encouraged every developer to build up the wish list for the next round, and through a public debate process we will get a clearer picture of a feature list in the next couple of weeks.

Planning the release will require us to figure out what will be reasonable to expect to include and what would be our stretch goals. We will start this process in very short order, because we want to get a tentative schedule out as soon as possible, so that developers around the world will know what to expect. For the Fedora Core 2 release I have been happy to notice that some projects have attempted to syncronize their release schedules so that we will have an easier time integrating their new code bases in the Fedora Core. It is my sincere hope that this trend will continue, and we are aware of the fact that we have to give people plenty of time to plan ahead.

LWN: According to the FC2 schedule, the SELinux functionality was considered "stop-ship" -- but it was disabled by default in the last test release. Is SELinux ready for mass consumption in the final FC2 release, or does it still require some polish before it's ready for prime time?

I think the SELinux functionality is pretty well cooked and I encourage the seasoned users and developers to play with it. Unfortunately at this stage, the implementation and management of the SELinux security policies are complex tasks that require an advanced degree of familiarity with the inner workings of the operating system.

The challenge we face in developing a default security policy is the balance one needs to strike between the level of security barriers deployed and the functionality people would reasonably expect out of this release. For example, can we subject third party applications, that are not aware of the security contexts, to a paranoid policy that most likely will prevent them from functioning correctly, or do we provide a more relaxed policy at which point the security advantages of SELinux are not so readily apparent? Also, the legacy of the discretionary access control setups will be a tough nut to crack - we found out that a lot of users still expected that the root account will be able to do and fix everything - an assumption no longer valid when running under SELinux.

So, for the Fedora Core 2 we have decided to court the experienced users and developers to help us figure out the lines of compromise between the challenges posed by the SELinux policy - a sort of a continued beta program for refining what would be an acceptable set of defaults. Of course, this does not preclude the development of very strict or more relaxed policies as alternatives to the balanced default set.

LWN: No doubt you've seen the parody published by Konstantin Ryabitsev about Fedora/Red Hat's interaction with the community. Though it's a bit over the top, it has raised quite a bit of discussion. Is it likely that RH will seek more involvement from the community in terms of setting the direction of Fedora? Will there be any changes in the way Fedora is managed in the near future?

This is and continues to be one of the challenges Red Hat faces - how do we build an effective way of engaging more of the external development community and how do we enable them to participate in this project. The parody you are referring to, while an entertaining read, assumes a political conflict out of the current state, when in fact the challenges we are facing are logistical. We are talking about deploying a parallel development process for the Red Hat developers, geared and built to support external parties contributing code on various sections of the operating system. This means planning and executing a huge change in everything infrastructure-related inside Red Hat engineering, which has the potential of causing big impacts in the other corners of our business, like support, professional services and even sales. We are working hard on opening up our infrastructure, but we have to do it responsibly and we have to be mindful of the business impact we are going to cause on the commitments Red Hat needs to fullfill as a publicly traded company. Oftentimes we internally compare this process to working on a jet engine while it is running...

Our short-term plans include the opening of a source code management repository where the interested developers can follow closely the development activity of the Red Hat engineering team. We will also be revamping the fedora.redhat.com website, adding dynamic content to it and allowing people to start participating in forums and start oganizing according to their common interests. These are steps that are going to happen in the very few next weeks, in time for the start of the Fedora Core 3 development process.

LWN: On the same topic, a lot of discussion has been comparing Fedora to Debian -- obviously, there are some serious differences in the way that both distros are put together. Would you say that the Fedora approach is better, or just different? Why?

Well, some things are better, some things are "different." The Red Hat engineering team is more experienced at putting together high-quality, commercial distributions. The planning, scheduling and focus we bring to the process are superior, and by transforming the Fedora Project into a community-focused release we now also have the flexibility of doing more of what is right when it comes to setting up a schedule.

In the software development process there are always three factors that are at play: features, quality and development speed. In commercial software development one can always have only two of those three. I believe that the community focus of the Fedora Project allows us to seek a more reasonable balance between those three objectives. Our background in commercial releases will allow us to keep focus on the fact that we need to have timely releases and we need to manage aggressively against the schedules we set. As far as Debian goes, they have been more successful at engaging the open source development community and there is a lot we can and will learn from their experiences. There is no question that as of now Fedora and Debian are very different in the way we put things together - but I think in the near future we will start to look more and more alike as far as the level of involvement with the development community.

That may yet happen, but the Fedora project is going to have to open up significantly before it can begin to shake off its image (in some quarters, at least) as a beta test program for Red Hat's enterprise products. With luck and work, perhaps Fedora can begin to approach Debian's level of community involvement. If this can be done while retaining Fedora's rather more predictable release schedule, so much the better.

(Log in to post comments)

Community involvement? Compared to other distros ...

Posted May 28, 2004 18:45 UTC (Fri) by ranger (guest, #6415) [Link]

On the participation page, we see that at present we may file bugs (as we've been able to do for most distros for years).

In future (it's said "soon" for over 3 months now), we will have CVS access.

Eventually, we will be able to build packages for Fedora (there is no mention of which packages the community will be allowed to help maintain, but it seems to lean towards only packages which aren't already in Fedora).

Let's compare that to another popular distribution:

1)CVS access, with commit access for trusted contributors (available in different forms for a number of years already, contributor commit access is about a year old).

2)Development discussion wiki (in addition to mailing lists), available for about a year.

3)A build cluster accessible by contributors (available for about 4 months, before that there was a single build machine for community contributors).

4)Packages in the main distribution maintained by community contributors, in most cases contributors who use the package (in the case of server packages) in production environments.

So, I still don't see the advantage to using the development tree for a linux distro I couldn't afford, and most of my clients can't either.

So, for the clients that can afford such a distro (and require it), I will continue to maintain my own packages of some server software (for instance that actually work with Red Hat's Cluster Manager where thier packages don't) until contributions are welcomed.

(so, "we" above may be taken to mean "people who haven't tried other community-oriented distributions")