The result of this exercise was to come to agreement on a number of recommendations. These recommendations now require buy-in from both RH engineering and Fedora community committees (especially FESCo and Fedora Project Board). When all parties are in agreement, then we will be able to aggregate a comprehensive project roadmap.
If you followed the IRC logs of the meeting, you can get a general idea of the kinds of changes that we are working on for the Fedora Project. Here are a few (not decided with finality) examples that I care about.
- Direct Contribution & Responsible Growth of Fedora Distribution Development
- This part is the largest change, which enables direct community contributions to improve the Fedora distribution at a faster pace, and with lower process overhead. Big changes however are often scary if misunderstood, so this will take place in careful steps and with well designed controls.
- Essentially all packages will become maintained in a manner similar to today's Extras project, but with more sophisticated controls, process and policy automation. Core will merge into Extras, creating one big distribution maintained by both RH engineering and Fedora contributors. The name for the new distribution is currently undecided, but may just be called "Fedora".
- All Core packages will go through a Packaging Guideline review before merging. An abbreviated review process was discussed briefly, and details still need to be worked out. A trickle of low-hanging fruit (usually leaf-node apps like squirrelmail or gaim that wont break deps) can begin with standard reviews sooner. Mass movement of packages to Extras is pending FESCo approval, where discussion begins during Thursday's regular meeting. I am personally accountable to this part of the plan.
- Project contributors earn promotion in community ranks through meritocracy. By doing good work of packaging, writing docs, fixing bugs or triaging, you earn respect and greater responsibility in project roles.
- These ranks are used by the source control and build system, to control who has access to certain parts of development. Finer grained ACL's will also be necessary to grant individual selected developers (like upstream) to work directly on certain packages. This system allows the Fedora Project to grow in a respnsible and controlled manner.
- Further improvements to plague will be necessary in order to create a suitable build system. The build system will need to be integrated with a Package Database of some sort. The Package Database is necessary in order to handle metadata in a more intelligent way than a buildsystem (like plague) that currently works from unintelligent targets of yum repo collections. This allows greater flexibility in widely distributed distribution development, while simultaneously allowing release managers to handle freezes necessary for releases. In the coming months serious help is needed at the Fedora Infrastructure team to help design & implementation of these critical pieces. Jesse Keating, the Fedora Project Release Engineer is accountable to this part.
- Fedora Project Board is soon mandating the creation of a fedora-scm SIG. This will probably be a mailing list and Wiki section. The mandate will have a limited lifetime with a deadline, because a decision needs to be made in a timely manner. Within this group further discussions and experimentation of CVS vs. mercurial vs. git (for example) will take place. Fedora Infrastructure team again is important to the experimentation and testing of SCM's, but it is ultimately up to the Fedora Project Board which software and implementation details are chosen.
- Red Hat is finally taking LiveCD seriously. The goal is to work with Fedora Unity, to push out an official FC6 LiveCD (and/or DVD) test as soon as possible, with FC6 Live coming soon after that. Then some serious work needs to happen with Jesse Keating's pungi to enable LiveCD to be released simultaneously with future Fedora releases. Discussions regarding development of LiveCD generation tools will be on fedora-livecd-list. If discussion does not take place in a timely manner, then the community should hold us accountable.
A much stronger software distribution and community project will take its place. There has never been a better time to get involved in the Fedora Project. Fedora contributors today shape the direction and accelerate the rate of progress of the entire FOSS ecosystem.
There were many other things in the works discussed, but I for now will take a nap. Others will be blogging soon about these topics, and Greg will be updating the Wiki with details and action items.