Interview with Justin Forbes (jforbes)

• Fedora Account: jforbes
• IRC: jforbes (primarily active in #fedora-devel, #fedora-kernel, #fedora-cloud)
• Fedora User Wiki Page

What is your background in Fedora? What have you worked on and what are you doing now?

I was involved in Fedora at the very beginning, and worked to get the port of Fedora Core 1 to x86_64 done. Shortly before the Fedora Core 2 release, I took a break to go work for rPath for a few years. I returned in the Fedora 11 development era and have been active ever since. Previously, I was the Red Hat point person for Fedora virtualization efforts, helped to get the Cloud SIG up an running, and have been a Fedora kernel maintainer for a few years now. I am both a contributor and a user of Fedora, and while I am happy to put effort into the pieces where I contribute, I also want Fedora to “just work” without a lot of effort as a user.

Do you think Fedora should be time based or more feature driven distribution? Or compromise?

There are advantages to both methods. I think we generally do a good job in balancing the needs here. Fedora has a lot of moving parts, each following different upstream release schedules. If we were completely feature driven, there would never be a release as there is always a project somewhere with a major feature “almost done”. I also don’t see much point in doing a new release without at least a couple of compelling features, but by tying these to a time based schedule, we can ensure that we actually get to a release with features that are expected in the time frame, and actually get a release out. Of course this doesn’t work 100% of the time, sometimes features just aren’t ready and have to be postponed until a future release. Sometimes (frequently) our releases get short delays to ensure that features are working as intended. But the compromise works, largely because of the community working to test features as they near completion instead of just waiting for a release to say something is broken.

What are the most pressing issues facing Fedora today (from engineering POV)? What should we do about them?

With the creation of flavors in the Fedora 21 cycle, we have identified and addressed some of the major differing use cases for Fedora. I think we still have some work to do in making sure we are offering optimal solutions for these use cases, while balancing maintainability.
I also think we have an obligation to improve the out of the box experience for new Fedora users. We need to make things a bit more intuitive. I know this is a broad scope, but specifically we need to find ways to make the user experience better without compromising the Fedora principals.

What are your interests and experience outside of Fedora? What of those things will help you in this role?

Outside of Fedora/Red Hat/Linux, I am a father of 3 kids. I have a pretty good amount of experience with looking at things from multiple sides before jumping to conclusions when there are opposing sides.

My other primary interest is in audio production and composition.

Anything else voters should know about you?

Not a whole lot I suppose, I have gotten pretty boring in my old age…

How can FESCo do a better job communicating with the rest of the Fedora community, or do you feel that FESCo is already doing well here?

I think FESCo does a decent job with communication for those who are paying attention. Meeting agenda and summaries are sent to the development list, which I think is the target audience for those items. Members will often blog about issues when necessary. Often those viewpoints do not reflect FESCo as a whole, but that is what makes FESCo actually work. There are going to be opposing viewpoints about some issues, there should be. The only thing I might recommend as an addition is a “state of FESCo” type blog post every so often that kind of makes happenings over the last month or so a bit easier to digest for the non developer who just wants an idea of what is going on.

What can you accomplish as part of FESCo that you couldn’t accomplish as a contributor to Fedora without sitting on FESCo?

I believe I can bring a unique perspective on some issues that come across, and it is another way to contribute to the Fedora community that I have benefit so much from over the years. I am not looking to come in with some sort of an agenda, FESCo exists to serve Fedora, not the other way around.

With the advent of Fedora Council now, what do you see as the significance of FESCO in Fedora project?

The move to the council has been a great way to make sure that most areas are represented in the high level leadership of Fedora. FESCo is more focused on the technical side of things. They compliment each other very well.

Do you think FESCo can help with the reduction of the backlog of >400 packages awaiting review?

I do think so, but it is not an overnight fix. We have to lower the barrier to entry in getting people actually involved in Fedora. This doesn’t mean lower our expectations of contributors, but to make it easier for someone who would be a great contributor to get involved. I think there are people out there who could make great contributions to Fedora who just don’t know where to start, or don’t think it is worth the effort to find out. Some improvement has been made in this area, but there is a lot more work to do.

What’s your point of view about library bundling in packages?

I think this has to be addressed on a case by case basis. There are several technical issues with bundling, but most importantly, bundling can create a world of mess, and ultimately leave users exposed to security risks that they believed had been addressed. As a baseline rule, they should not be allowed. If there is a very compelling argument as to why bundling is the only feasible option, exceptions can be made. They have to be handled as exceptions though to keep things from spiraling out of control to where no one actually knows what Fedora is really shipping.