In my continued exploration of Fedora’s Four Foundations I arrive at Features. I am not going to recount the feature set of Fedora 9, or even the upcoming Fedora 10. Features change and so inherently they are in and of themselves not foundational.
What is foundational is the way Fedora approaches features. The first approach is one of ownership. Now by ownership I don’t mean they necessarily own the code, but rather that they take responsibility. For instance with SELinux, Fedora as a community of users and developers took ownership of SELinux and made it usable. The community brought about things like setroubleshoot to make SELinux more manageable, but it’s really the widespread use of SELinux that Fedora pushed that brought it to where it is today. That’s ownership of taking a relatively ‘raw’ feature and integrating is why SELinux has become the standard mandatory access control for Linux.
One of the ways Fedora takes ownership is making sure the effort isn’t a one-off to work in Fedora. By that I mean that if a patch is required to fix a problem with a package, it is almost always contributed upstream to the project. As a matter of fact there’s a documented policy on pushing patches upstream. That benefits the upstream project by fixing bugs, it also benefits Fedora. If every package in Fedora had it’s own one off patches that means that the package maintainer would be responsible for keeping the patches updated as well. That quickly scales out of control. In addition it means that if there is a bug or enhancement the patch provides that the upstream project has to reinvent the wheel, which is both inefficient and contrary to the spirit of open source software. The Fedora Project as a whole recognizes both the pragmatic and the philosophical benefits to pushing patches upstream and that’s the default policy.
Fedora is known for tackling large swaths of Features at every release, and a lot of those features come from within Fedora or through Fedora from Red Hat. Recent examples such as Network Manager, Plymouth, Ovirt, Func, and Cobbler, illustrate this very well. Fedora isn’t content building a distribution from the work of others, though it certainly couldn’t begin to without the valuable contributions from the larger open source community. However Fedora realizes that building a distribution, making is usable and successful requires some work as well. So when a deficiency is seen, people begin working to solve it, and in the process they make the larger open source community better for it.
Part of the reason for Fedora’s reputation with features is the way it approaches them. For a feature to make it into Fedora, there has to be a proponent within the community. That feature proponent is responsible for more than making the suggestion. The owner is responsible for communicating, creating test plans, contingency plans, and making sure the feature itself is ready for inclusion. There are also some checks along the way - for instance the Feature Wrangler ensures that the feature proposal is complete, that all of the requirements are met, and performs a sanity check. Once the Feature Wrangler has ensured completeness and sanity the proposal moves to Fedora’s Engineering Steering Committee. This is a community-elected committee that determines which features will make it into the next release. Virtually all of this process takes place on IRC, in email, or on the wiki. That makes it all publicly viewable, and holds all of the parties accountable. This also helps generate excitement behind upcoming features, perhaps even more contributors to work on the feature. This entire process makes sure that features are ready at release. This does mean that some features don’t make it in, or are delayed, but it insures a higher quality release.
Fedora is known as a ‘feature-full’ release, and indeed features are a defining element of the Fedora Project. Fedora’s community approach coupled with its strong focus on proper engineering ensures that it is
..
Complete Story
0 comments:
Post a Comment