This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.
Interview with Owen Taylor (otaylor)
Questions
Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?
The Fedora project has been moving decisively in the direction of increased flexibility and diversity – with Modularity, with new distribution mechanisms and formats like ostree and containers. One of our big challenges is to able to take advantage of all this flexibility and still provide a stable, easy to understand experience to our users. I’ve been involved in desktop Linux from the days of editing your window manager and XFree86 configuration manually to the current point where have slick desktop environments that just work. I’m familiar not just with the technology, but also the design processes we’ve developed, and the tricky balancing act between keeping things streamlined and accommodating the needs of advanced users.
What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?
There is a lot of work currently going on in Fedora to separate out
the operating system layer from the application layer – Fedora CoreOS,
Fedora Silverblue, and our container and Flatpaks efforts all represent
aspecs of this. FESCo should be continually keeping these ways of
consuming Fedora in mind.
A personal interest of mine is how developers work in these new
models – how do Fedora users develop their applications, and how do
Fedora developers develop Fedora. Our traditional model, where the
operating system and applications emerge from a great big sea of
packages gives a ton of flexibility, and once you move away from it, it
feels a bit like putting handcuffs on, but I think there’s a lot of
value to be found for developers as well – to be able to have different
development setups for different applications, and to be able to try out
operating system changes in ways that are well contained and easily
reverted.
At times, it seems like FESCo can get a bit bogged down in the
nuts-and-bolts of fixing the operating system – and while that’s
essential work, I’d hope that some of that work can be delegated and
FESCo can concentrate a bit more on high-level issues and what Fedora
needs to do as a project to enable a better operating-system /
application split.
What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?
I think it’s generally agreed that the weakest part of our process is the “compose” step – taking the bits we create and making an operating system image out of them, reliably and quickly. Not only does this hamper our ability to fix bugs, it is a huge limitation in our ability to do integration testing – any packager who wants to update a system image or component should be able to get tests run on the entire operating system with their component included. In fact they should be required to get such tests run. I think there are some good efforts out their to improve things – FESCO can help out by directing focus towards those efforts and by continually pushing back when a “broken operating system” problem comes up – not just helping out with an immediate fix but figuring out why it wasn’t caught by automated testing.
Recent Comments