Google Summer of Code Mentor Summit Report

I’ve been talking with a number of Fedora leaders, principals, and team members about the issue of Fedora lifecycle. Lifecycle here means the way we manage, schedule, and populate Fedora releases. I started the Lifecycle objective and proposed it as a lead to the Fedora Council to house what I hope will be improvements to Fedora lifecycle.

One of the most important goals is to diversify the community ownership of our releases. This involves a fairly extensive set of changes in Fedora. It will need effort from a number of teams that work on release processes and services. For that reason, I’m proposing we pause the release cycle after the release of Fedora 30.

I posted this morning to the devel list to start gathering feedback and input from a wider group on the ideas around the ideas in the writeup. The most important feedback comes from those who are involved in those processes and services. But constructive feedback is welcome from any part of Fedora. Please take the time to read the whole document and understand the goals and benefits for Fedora.

One side note: You may have seen an earlier thread from Matthew Miller about a longer-term maintenance release. The Lifecycle objective would certainly make that possible. But the point of the objective is not that in particular. It’s to allow more flexibility in what we release and when — and thus make Fedora more interesting and hospitable for many more people to participate in, and build on, the project deliverables.

I’d like to express gratitude for participation by Matthew, Jim Perrin, Adam Williamson, Josh Boyer, and others to illuminate key ideas and issues that found their way into this draft and other conversations. While it’s true that any open source community can excel at collaboration, Fedora folks like these really do walk the walk!

Photo by Kosta Bratsos on Unsplash.