Interviews/BillNottingham

File:Interviews BillNottingham Picture.jpg

Bill Nottingham at FUDCon Boston 2007

Picture taken by Christopher Blizzard

IRC Nickname: notting

Location: North Carolina, USA

Age: N/A

Profession: Red Hat Engineering, Fedora Project Board member.

Blog: N/A

• Date of Interview: 13th January 2007
• Interviewed by RahulSundaram

Hello, Can you introduce yourself briefly?

Hello, my name is Bill Nottingham. I'm a long-time Red Hatter, and have been working on Red Hat Linux since 5.2, and Fedora since its inception, serving on the Fedora Project board.

Can you tell us more about what you do you on a day to day basis in Fedora?

On a day to day basis in Fedora I do many things - I maintain packages in Core and Extras, and contribute the occasional fix to various other packages. Over time in Fedora, I've done everything from release coordination, feature planning, mirror list handling, writing of announcements and release notes, testing and verification, random package scrubbing, freeze handling and review, schedule making, bug triage, etc., etc. These days I'm spending most of my time on Fedora 7 planning and the various features and work that need done for that.

Talking about Fedora 7, you posted a long list of major improvements planned for the next release recently. Which ones do you think will actually make it into the release? Which planned change is your favorite one and why?

Well, I hope that all of them will make it in. True, some of the features, such as the "juju" firewire stack , RandR 1.2 support , and others , are dependent on upstream code acceptance and availability. But the idea was that these are all things that should be doable.

As for which of the features are my favorite, I'd have to say it's the infrastructure around merging Core and Extras, and then the ability to do separate [[Releases/FeatureFedoraTargettedSpins|'spins' of Fedora] . We've long talked about removing any qualitative distinction between Core and Extras, and the best way to do that is to have everyone working in the same pool , towards the same release. In the Core and Extras world, a package's location would be dependent on factors such as what packages required it to build, or what other packages were built from the same source RPM. By merging the two repositories, we get to the point where we don't have to worry about those sorts of technical details which are really quite irrelevant to what users want; we just pick the best software available and put that on the release images.

Moreover, by giving the world the tools to make their own 'spins' of Fedora software, we empower anyone with an idea to meld the software to suit their own needs. Right now there are people debating how to best put together targeted releases for a KDE desktop. Later, someone might want to do a release that showcases all the best open source games, or a release that is a webmail-server-in-a-box. I'm sure there are more great uses that I can't even imagine now. We want to foster that sort of creativity.

How has the plan of merging core and extras been received by the Fedora Core developers within Red Hat and the Fedora community? What kind of changes are necessary to accomplish this?

It's a change to how everyone works - for those who maintain packages for Core, they have to go through a new account process and use a new build system; for those who maintain packages in Extras, they will have work with more stringent freezes and update policies. Whenever you make large changes, there is going to be some dissent, but most reaction has been positive.

We're making various infrastructure changes to allow this to go more smoothly; We're introducing some of the features we've had internally, such as access control lists and automatic e-mail notification of changes, into the combined source control system. Every package that's being brought over from Core will have a review initiated, to make sure all the packages are up to the same standard. We're also planning on fairly significant changes to the backend of the build system to make the life of the release engineers assembling the system much easier.

How easy is it to create a custom spin or derivative of Fedora now? Are there any new changes in the pipeline to make this easier?

I've not built a custom tree in a while, but, at minimum, you'd have to assemble the repository of RPMs yourself, regenerate the package metadata, potentially split it into CD-size chunks, generate the CD metadata, and remake the installer images with the new metadata. It's all doable, but there's a bit more voodoo than we'd like.

We're working on making this easier in multiple areas. First, we're planning on making it so that the installer images are independent of the tree being installed. Secondly, we're introducing the Pungi tool , which simplifies and automates the steps needed to go from a tree of RPMs and a package list to a set of installable images.

Pilgrim has been announced recently as a tool to create custom live CDs from Fedora packages. Is that related to Pungi in any way? Are they going to be merged?

In as much as they are both new tools that we're going to be using during the Fedora 7 cycle, they are related. They do not as of now share code, and there aren't plans at the moment to merge them into a single tool.

Fair enough. Can you tell us something about the the idea of investigation new init technologies? Has anyone looked at it already?

The 'new init' feature isn't really a feature targeted for the next release as much as it's something to be worked on during this release cycle. There have been various new technologies developed recently for use during system initialization, including upstart, D-BUS service activation, and launchd. As this is a major change to how core parts of the operating system work, we would like to make sure we do our homework before we switch to any combination of them. There has been some prior research done into this, although that was mainly done on initng, which is looking less like a choice.

Is the research done on initng available publicly? What is not appealing now?

I believe what was done is in the mailing list archives. As to initng, it's just that upstream development has slowed recently, and other projects seem to have more momentum. Of course, more research could change the direction of what we're going to do.

[Interviewer's Note: Initng is in Fedora Extras nevertheless]

Thank you for your time. Any parting words?

No problem. It's an exciting time to be working on Fedora.