I worked with FPL Matthew Miller and our engineering manager Jim Perrin, among others, to define the various problems we want to solve in diversifying the Fedora lifecycle. We're seeking review and feedback from community members. The most salient feedback will be from those involved in the efforts we describe, but we welcome all constructive feedback. Here's the summary from the page, which proposes we pause the release after F30 for these efforts: * * * Fedora’s singular lifecycle has been in place for almost a decade and a half. During that time, technology users have changed how they consume platform and applications. Fedora needs to be more toward the forefront of these changes. But more importantly, Fedora needs to be more hospitable to community management of lifecycle. Currently Fedora can’t scale for more community ownership of the things we release: (1) Only a few people can build and push out releases; and (2) we manage releases largely based on that staffing. The Fedora community should be able to run releases of content themselves, using tools that work well, with only minimal oversight, and determine their own schedule for doing so. This implies a great deal of both redesign and reworking of tools and processes. To unblock the community, several things need to happen. We need a faster, more scalable compose to enable CI/CD operations; we need to automate more testing and quality measures; and we need to update our delivery tools and processes. We also need to track and coordinate this work across teams, since it involves collaboration among Fedora infrastructure, QA, applications, release engineering, CentOS CI, maintainers, and more. We should skip the F31 release cycle and leave F30 in place longer in order to focus on improving the tooling and testing changes. These tooling changes will improve the overall reliability of Fedora, and will decrease the manual effort and complexities involved in producing the distribution artifacts. Although we’ve done this before to make “editions” happen, the intent is to track this multi-team effort more actively so we can (1) use the time as well as possible, and (2) give the work maximum transparency. * * * The full page is here, with a set of problems, solutions, and actions proposed. I invite you to take time to read it in detail: https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements I also attached that page to the main Lifecycle objective page here, which was previously approved by the Council: https://fedoraproject.org/wiki/Objectives/Lifecycle Rather than try to spin this one email into a thread of doom that people will give up on reading, I encourage those with feedback to open a thread for any particular topic. That way the community discussion should be more useful for all. I'll collect input and use it both for responses and to help tweak plans for (hopefully) optimal results. I'm on vacation next week, for which timing I apologize. But I'll try to look at mail here from time to time and when I return. -- Paul _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
