< Development | SteeringCommittee | Nominations
FESCo Elections Interview with Adam Jackson (ajax)
This is a part of FESCo Elections interviews series.
Voting is open to all Fedora contributors. The elections started on January 26th and closes promptly at 23:59 UTC on February 3rd.
Please read the responses from candidates and make your choices carefully.
Interview with Adam Jackson (ajax)
What is your background in Fedora? What have you worked on and what are you doing now?
I started using Fedora in late 2005 with Fedora Core 5, the first release to ship the modular X11 packaging from Xorg 7.0. I've worked across the graphics subsystem to improve maintainability, stability, and performance. I've made significant contributions to X autoconfiguration, the kernel's EDID parser, DisplayPort enablement on i915, GLX, the XFIXES extension, and Xinerama/Composite integration. I've made driveby contributions to dozens of packages, and served on at least one prior fesco. Currently I'm working on improving OpenGL under Wayland, in particular on feature parity and interoperability with X11 and peaceful coexistence of multiple vendors' drivers in the same GL stack.
Do you think Fedora should be time based or more feature driven distribution? Or compromise?
I don't really think either of these things; I think the question is imprecise.
Asking what to do about "the" distribution reflects a mentality where there is exactly one thing being released. With the new product model, that's clearly not the case, which means we need to define what we mean by "Fedora" and by "distribution". Personally I think of Fedora as meaning the collection of branches in package git, and the distributions as being the products composed from that. (If I may make an analogy to Android, Fedora is AOSP, and Workstation is the vendor's firmware image. Certainly you can run AOSP if you want, but it's a fairly raw choose-your-own-adventure experience.)
In that model, Fedora obviously doesn't have any particular feature driving it; it is merely the collection of the newest stuff that has been made to work (for whatever value of "work"). The products have both factors pulling on them - as the OS ages it eventually won't install on new hardware, for example - but successive product releases continue to be interesting to the extent that they are not merely new but novel, doing new things, incorporating new features.
The question then is how to arrange Fedora to best enable merging features that enable interesting projects. Time-based branching is certainly one strategy for that. It's a model people are at least familiar with, if not necessarily comfortable; it allows for planning against upstream schedules; and if it doesn't promise novelty it at least promises currency. Given we have no real alternative proposals, I can't advocate for abolishing time-based branching, there needs to be something to plan around. More interesting to me is the challenges faced by any particular feature merge, and that we don't just wedge features into an existing design but fix our own tools and processes to match. (Imagine, for instance, if we built rpms using something nicer than rpmbuild; how would we migrate away from spec files?)
What are the most pressing issues facing Fedora today (from engineering POV)? What should we do about them?
Release engineering. We need a systematic review of our releng processes and tools, and we need to fix them to the point that we're not constantly doing fire drills at release time trying to get things out the door. We should probably consider alternatives to rpm spec, for all the same reasons that gnu changelogs are terrible. We need sufficient tooling around package git to make it easy to branch from a Fedora base, build your own overlay repos, and keep them up to date as Fedora moves ahead. We need to accept that library bundling will sometimes be unavoidable, and we need tools to track and manage that.
It's not much to look at, though careful observers will note the translucent top bar: https://ajax.fedorapeople.org/desktop.png
What are your interests and experience outside of Fedora? What of those things will help you in this role?
Oh, the usual. I read, I bike, I snowboard, I play music. Not sure how much that helps in a fesco context, other than reminding one that there are more important things in life than arguing about computers.
Anything else voters should know?
Be excellent to each other.
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?
It might be interesting to go beyond just the "meeting minutes" style of reporting and write something more in the spirit of an LWN article or blog post. There's a lot of context around fesco issues that isn't necessarily obvious to the casual observer.
What can you accomplish as part of FESCo that you couldn't accomplish as a contributor to Fedora without sitting on FESCo?
It forces me to take a more active interest in parts of the project that I wouldn't normally, and it means I can vote, but other than that I don't feel like it gives me any particular superpowers. Most of the things I'm personally interested in are things I can accomplish as an individual contributor.
What degree of leeway do you feel that the Working Groups should have to diverge from one another in establishing their own identity?
As much as they need? I think that'll be a more interesting question once there are enough working groups with sufficiently different visions for their products.
How would you define the set of criteria for promoting a spin to a product? What about the reverse?
I think a spin becomes a product when it has a vision and a set of goals that exceed the mere packaging of bits and extends to actual social or technical progress. If all you're doing is installing Fedora with blackbox as the default window manager, that's a spin. If you're building a workstation OS for developers and content creators, and engaging with external projects to fix their bugs and write cool new features, that's a product.
With the advent of Fedora Council now, what do you see as the significance of FESCO in Fedora project?
I don't think it's much different than the previous relationship with the Board. The council creates social consensus, fesco creates technical consensus.
How "closely" do you, as a member of FESCO, follow the devel mailing list before voting on FESCO meetings? In other words, apart from your own technical qualifications, what is your typical process in arriving at decisions?
I read devel@ pretty much daily, at least as far as scanning subjects for personal relevance. When the agenda is sent out for an upcoming fesco meeting I make a point of reviewing the tickets and any on-list discussion so I can come prepared.