LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for June 14, 2007An interview with Fedora leader Max SpevackNow that Fedora 7 has been released, Fedora project leader Max Spevack has a little bit of breathing room. Like nature, LWN abhors a vacuum, so we sent Max a list of questions and a request for answers. We are now happy to present the answers. Without further ado...LWN: Fedora 7 is out. Congratulations! What do you think is the best single thing about this release, and what do you most wish had been done better?
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. So what can we expect for Fedora 8?
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. What can you tell us about the longer-term plan for Fedora? Where do you think the project will be in 2-3 years?
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. There has been some grumbling from the ranks of (former) Fedora Extras maintainers that the new update process just adds bureaucracy to their job. Has anything been done to make those maintainers happier?
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:
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. Whatever happened to the proposed developer ranking system? Is that still something the project is considering?
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.
Red Hat still maintains a fairly firm control over parts of the project; the decision to not consider outside artwork for Fedora 7 is one example. Do you expect that to continue, or will the Fedora project become more independent over time?
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. The development process at rpm.org has been quiet for a while (though a look at the lists shows that some things are happening). Meanwhile, the other RPM has launched rpm5.org and appears to be headed toward a major release. How do you feel about the state of rpm.org development, and is there any chance of joining this fork sometime in the future?
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. Many thanks to Max for taking the time to answer our questions in such detail.
SourceForge: the "Hotel California" of open source projects?You can check out any time you like, but you can never leave SourceForge (SF) provides a valuable service to the free and open source software communities, but it is not without its flaws. It is quite common that, as projects mature and gain popularity, they move away from SF for a variety of reasons. Unfortunately, because of a well-intentioned data retention policy at SF, this can lead to projects held hostage by the high regard search engines have for SF. SF is one of the earliest providers of free hosting for projects claiming over 100,000 projects with over one million registered users. It provides source code repositories, mailing lists, bug tracking, download space for releases, and has recently added wikis for the projects hosted there. For many small projects it has been an essential part of the infrastructure. It provides a way to draw developers' attention and it is a place for users to get information and releases. At least partially because of its popularity, SourceForge has its share of problems. Complaints about the tools chosen, user interface, number and type of advertisements, etc. are commonly heard. Perhaps the biggest issue for most projects is the availability of the site. Development grinds to a halt if the SF server goes down; communication disappears without the mailing lists and, because it uses centralized source code management, no code can be checked in or out. SF becomes the single point of failure for the entire project. If a project gets unhappy enough with SourceForge, they can, of course, just pick up and move elsewhere. There are other project hosting sites available, some geared towards particular kinds of projects. It is likely that other sites suffer many of the same shortcomings as SF, so projects often find their own host, where they can control the tools and advertising policies. They can also impact the reliability issues by choosing tools that are less centralized. To their credit, SF does nothing to discourage projects from moving, but they do have a policy regarding what happens to the project's data and, ultimately, to the project's SF entry itself. A weblog entry by kernel hacker Dave Jones gives his opinion, rather forcefully, about the retention policy. It seems he had tried to have his x86info project removed from SF, but was foiled by the policy. This rubbed him the wrong way:
My biggest beef is that of ownership. I feel I've effectively been
forced to fork my own project. As I understand their policies,
the terms mention that they won't remove projects that have
released code just in case someone wants to fork an earlier version,
or see the older history. In my case, I have a complete preservation
of history in the git tree imported from the original CVS, along with
tarballs of all releases.
Should someone wish to fork my project, they'd be far better served
by grabbing either of those than the 4 year old code stagnating
in the CVS attic at sourceforge.
Search engine ranking plays a big role in his annoyance as well. A page at SF with a particular project name attached to it will be very high or at the top of any search engine results. Anyone looking for the project is likely to end up at the SF site, which will require another hop to get to the active site, if they see the link, as Jones puts it:
So now I'm left with one
line of text forwarding to the new site, amongst a sea of commercials
for sourceforge's "services".
The policy is for the protection of the code and the project, so that a loose cannon project administrator cannot, in a fit of pique, get the project and all of its files deleted. It also protects against data loss when projects move, but then disappear from their new site. There is certainly nothing wrong with the policy per se, but it has some, probably unintended, side effects. SF has a built up a well deserved reputation as a solid, if a bit annoying, home for projects, and it certainly cannot be faulted for the trust that search engines have in it. There is also nothing wrong with providing a repository for old releases of open source software. It would just be nice if they could provide what Jones calls the "yes, I really know what I'm doing, and I understand your reasons, but please kill this project" option. In some ways like the trademark issue described on this page last week, this adds another decision that a project leader may need to consider in the early stages of a project.
The first LiPS specificationsThe Linux Phone Standards Forum is an industry group aimed at standardizing the use of Linux in telephony applications. Its members include some service providers, embedded software companies, chip manufacturers, and so on. There is, interestingly, a distinct lack of representation from handset manufacturers in the group currently. LiPS has recently announced the release of the first set of Linux telephony specifications. This work is far from complete, but it is enough to give an idea for where this group intends to go. For those who would like to look at the whole thing, it can be downloaded as a zip file filled with files in PDF and HTML formats.One of the first things that one notes is that LiPS is not about free software. The (minimal) software associated with the specification can be distributed under a somewhat BSD-like license, but any necessary patent licenses can only be had under "reasonable and non-discriminatory" (i.e. discriminatory against free software) terms. LiPS is very much about making it easier to create proprietary applications for the phone space. One set of specifications covers basic user interface tasks - how the arrow keys should work, APIs for text entry, etc. LiPS appears to have settled on GTK+ as its toolkit of choice for this purpose despite the presence of Trolltech in the list of members. There is some evident concern about the size of the GTK+ library, leading to a specification of which widgets are necessary and which can be removed. Specifications covering the customization of the look and feel of the device are planned but not yet present. Then, there's a set of "enabler" services. Those which are present currently include a discussion of address book services and basic voice call management. There is much more planned in this area, including calendars, messaging, web browsing, data synchronization, video calling, and, inevitably, "DRM". Other areas which have not been filled in are "application management" and "OS services." Application management covers the launching and control of applications and some API-level things like inter-process communication. The OS services category is a large one; at the lowest levels it will have a set of "requirements on the Linux kernel and drivers" and some sort of database service. On top of that one finds things like network protocols, power management, dealing with SIM cards, etc. One imagines that the specification writers will be busy for a while. Some of the missing documents are planned for later in this year, with the rest completed in 2008. Most of this is relatively boring stuff for people who are not actually working in this area. It may turn out to be important work for those who would like to see Linux World Domination in the mobile telephone arena, though. If it is to achieve that goal, LiPS will want to broaden its membership; the lack of presence by the companies which are actually shipping Linux-based phones is worrying. The creation of a software stack which is truly free software would be a good addition to the Forum's goals; if a phone is completely proprietary and locked-down, the fact that it is running Linux will not be especially helpful or interesting. If the Forum can become truly inclusive in these ways, perhaps its specifications will be more than just LiPS service.
Page editor: Jake Edge Inside this week's LWN.net Weekly Edition
|
|||||||||||||