Linux.com

The Fedora Summit drew 10 top Red Hat and Fedora team members to the table including Jesse Keating, Fedora's release engineer; Fedora developer Jeremy Katz; engineer and original Fedora Project founder Warren Togami; Greg DeKoenigsberg, community development manager for Red Hat; and Fedora Project Leader Max Spevack. In addition to a conference call established to accommodate team members unable to make the trip to Massachusetts, the meeting was also transcribed live in an IRC channel that drew more than 100 members of the Fedora community.

Though more than 30 topics were discussed during the Summit, a handful of issues consistently stood out as areas of importance. Participants spent a long time talking about ways to lower the barriers for community involvement, since nearly everyone agreed that significant contributions to Fedora have been made by both Red Hat employees and community members alike. A current proposal on the table seeks to make the most of that strong blend of contributors by doing away with the delineation between Fedora Core packages, which are typically developed and maintained by employees of Red Hat, and Fedora Extras, which are most often developed by volunteers within the community.

"The big ticket item, from my perspective, is getting rid of the divide between Fedora Core and Fedora Extras," said DeKoenigsberg. "Community contributors have proven conclusively over the past 18 months that they can build packages every bit as well as Red Hat engineers -- better, in some cases. So articulating that goal more clearly, and putting a road map in place to get us there, was extremely important to me."

Project Leader Max Spevack agrees. Under the current system, Core package maintainers must be employed by Red Hat. "But we want that to change," he says. "We want to be able to have the best qualified person for the package. If that's a Red Hat person, fine. If not, that's fine too. When you're dealing in open source software, the community is very important. At the end of the day, all the various distros are more or less the same. The difference is how well you enable the community of users to participate in the project. We're trying to put things in place that will give the community more say, because we think it leads to a more vibrant and healthy community. It's about finding the best people and giving them the ability to make changes."

As a means to that end, Fedora recently posted a job opening for an Infrastructure Leader whose primary responsibility will be to use a combination of engineering and management skills to oversee the implementation of several key items that were identified at the Summit. Spevack says initial response to the job posting has been large and they hope to fill the position in early January.

There was also a tremendous amount of enthusiasm surrounding plans to create new build tools in time for the release of Fedora Core 7, which is still several months away. Red Hat currently uses Brew, an internal build system, to create and distribute Core packages, and Plague, a distributed package build system that uses programs such as mock and yum to power the process, when building Extras. The Fedora team is now in the process of evaluating what build systems will best serve developers and still allow community members the freedom to create their own packages.

Hand in hand with a revamped build system is the advancement of a live CD project. Red Hat has long been interested in the development of a live CD distribution and even sponsored a related project, Kadischi, during Google's 2005 Summer of Code. That project has stalled, but developer and maintainer David Zeuthen, best known for creating Red Hat's Hardware Abstraction Layer (HAL), which lets applications easily identify system hardware, has steamed ahead with his live CD tool, Pilgrim. Pilgrim creates system images that can run from flash drives and, according to Fedora's live CD Proposal, "maps very closely to the goals for a proper Live CD."

After reviewing both Pilgrim and Kadischi, summit attendees chose Pilgrim because of Zeuthen's strong leadership of the project. Since Pilgrim will be used by both Fedora and the One Laptop Per Child project, attendees also felt that it offered the potential for an exceptionally strong codebase due to the large number of people expected to be constantly reviewing and tweaking its code.

Spevack says establishing a clear direction on which build and live CD tools will be used was crucial to overall game plan established at the Summit. He says the team would like to give the community the tools it needs to build packages that are meaningful for individual users, as well as offer the ability to let people create ISO images to share and distribute their work. "We want to make arrangements so there's no dependency on Red Hat to make Fedora into what you want it to be for you," he says.

Of course, such significant changes to the Fedora Project impact the release process, but team members say the goal is to determine the best method to structure the process in a way that blends Fedora Core and Fedora Extras under one umbrella. Spevack says that as the implementation of the overall changes takes place, a new release process will emerge on its own. "Since we want to have the best maintainer for a package, the barrier and the distinction between what is 'Core' and what is 'Extra' becomes semantics."

Spevack says that support for Legacy, a community-based project that offers support for older versions of Fedora, is expected to be extended a couple of additional months as well and that will also impact the release process. He stresses, however, that he wants to make sure no one is displaced by any of the changes, but rather moved around as needed to maximize their talent.

Keating, Legacy's original team leader, echoes that sentiment. "When I started Legacy, I had high hopes of providing expedited updates for the Fedora and Red Hat Linux [versions] we claimed to support. Ultimately as a project we weren't able to deliver this. Partly it was due to a small number of people wanting to contribute, and partly I feel it was my management of the project. Either way, it is very clear that we were not able to give the update support we set out to provide with the later Fedora releases (FC2/3/4).

"There are people contributing to Legacy currently that have no vested interest in Legacy. They just want to help out where help is needed, and possibly get some name recognition. I think that the Fedora Project could make good use of this energy and manpower in more productive projects. It would be a shame to close the door and leave the contributors in the cold. I would really like to find them new homes for contribution."

Though support for Legacy will clearly change, at the time of Keating's interview, its fate had not been decided. "A few months ago I passed leadership off to one of my contributors, when I could no longer dedicate any significant time to the project," says Keating. "We came up with a proposal for Legacy at the summit, but it's up to the current Legacy leadership to accept the proposal and end the project."

On December 12, however, the Legacy Project's homepage bore the following message: "The current model for supporting maintenance distributions is being re-examined. In the meantime, we are unable to extend support to older Fedora Core releases as we had planned. As of now, Fedora Core 4 and earlier distributions are no longer being maintained.... This will be the complete end of Fedora Legacy's support of the Red Hat Linux line of distributions. We will continue focusing our efforts on the Fedora Core line, and improving our integration with the Fedora Project in whole."

During and after last month's Summit, some community members suggested that the Fedora team's recent interest in short- and long-term planning may indicate that Fedora feels the need to justify itself to the larger Red Hat community. Spevack says nothing could be further from the truth. He says developing a plan for the future is just good business sense.

"Red Hat is a big, publicly traded company, and I think they are looking at Fedora from multiple perspectives. When Red Hat makes its decisions, it wants to know it's doing what's best for the company as a whole. Red Hat wants to see things like this Summit and have us say, 'Here's our road map, here are the ways we think we're going to improve,' so the investment Red Hat makes in Fedora will prove to be a good one for the overall company. I think it's good that the executives want to know that the people they've delegated to have a good plan, and I don't think that Fedora requires any more or less justification than any other part of the company."

Now that the Summit has drawn to a close, it's time for the heavy lifting to begin. The new proposals must make their way through an assortment of committees and boards before they can be fully implemented. Community members are encouraged to read the IRC logs and Summit wiki and also offer feedback to the team. "I think that across the board, everyone likes the overall vision," says Spevack, "and now we're in the 'answering specific questions' phase. The major 'doing stuff' phase will probably begin in earnest after the new year."

Share    Print    Comments