This is a part of FESCo Elections interviews series.
Please read the responses from candidates and make your choices carefully.
Feel free to ask questions of the candidates here or elsewhere!

Interview with Dennis Gilmore (ausil)


I started with fedora way back in as a packager, I got involved in Fedora infrastructure when we had 3 servers and half a dozen builders. Over the years I have been on FESCo and the project board, I worked with Mike McGrath to start EPEL. Worked with Tom Callaway to start Fedora Secondary arches. Currently I am the lead for Fedora Release Engineering and am working to enable us to more flexibly deliver Fedora and making sure that Fedora can grow and embrace the changing IT landscape.


I think we have to have a compromise of sorts. I would like to see us work on time based landing of features,  regular points in time where we can talk about new things delivered to users in stable trees, but I would like to see us move more to a series of rolling releases.
The ultra stable series where we land things occasionally, mostly it is bug fixes kinda like Fedora n-1 today. where it is stable and solid but every six months or so we push a new set of rock solid bigger changes out to it, this is what I would install for my mum.
Then we have the stable series which is like fedora releases today. Stable and solid but slightly more change and allow people try out new things sooner.There would be new features more often. Maybe every 3-6 months we promote changes to stable. The user here would be someone tech savy who wants the latest cool things but does not want to deal with a firehose of updates and doesn’t want to deal with some pieces being unpolished and a bit rough.
Finally we would have a development tree, where we land new features  regularly. Changes would get isolated and tested some before landing,  this is where Fedora developers should live, it would not eat babies and kill kittens. But be somewhere that we can land the latest GNOME or KDE and get testing. New features could land any time. Sometimes there is polish that needs to happen, but for the most part everything should work okay.
On top of the development tree we would have env and stacks where people can experiment and try out radically new things.  When they are deemed stable enough for general consumption they get folded into development.


The biggest pressing issue is keeping up with the rapidly changing IT landscape. The traditional IT model will stay around and will continue to need to be supported, but we need to embrace new ways to build, and ship software. We need to try the new thing that comes along, we need to drive the new thing that comes along, we need to be willing to go that did not work and drop it.  We should not continue to offer things that make no sense anymore.


I play American football, it helps me to keep focused and follow a plan.  I also like photography and showing my daughter the world around us.

Anything else voters should know?

I am extremely passionate about Fedora I love doing what I do. I want to make sure it succeeds and is always deliverable.  I am working to change as Fedora and the IT world changes, and ensuring no one ever says again that “Release Engineering” is a black box.


There are many many parts of Fedora that do not do a great job in communicating. I do not have a bullet answer to fix that, but it is an area that needs to be addressed. Not just FESCo but many other parts of Fedora.


Help to ensure that Fedora embraces change, but makes sure we do not Run before we walk.  Given my job I can do some of that without being on FESCo but it would be easier within FESCo and hopefully can ensure that we avoid conflict by ensuring there is better communication and visibility into the release engineering side of Fedora.


I do not think that the council greatly changes the significance of FESCo. If anything it enhances and gives FESCo somewhere to be accountable to. The way things were before the Board was completely hands off in the engineering side. Now the Council can set long term goals, FESCo can set the short term goals to achieve them and they can work well together for the benefit of Fedora.


FESCo can help by looking at the processes and work to eliminate bottlenecks. By working with QA to get better automated testing setup we can look at automating parts of the review process, and simplify things overall without sacrificing the quality of Fedora.