On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor <otaylor@xxxxxxxxxx> wrote: > > On Mon, Nov 26, 2018 at 9:26 PM Brendan Conoboy <blc@xxxxxxxxxx> wrote:> > > On 11/16/18 7:50 AM, Paul Frields wrote: > > [snip] > > > 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. > > > > If there is going to be a pause F30 seems like a good place to do it: > > New glibc, new compiler- and a full year for them to mature. It's a > > nice basis for a stable platform. What would the update policy be for > > this year- same as today? It seems like you're proposing this as a > > one-time event to pay down technical debt, which is great, but would > > you perhaps consider doing the same thing for F31, F32, etc? The > > basic reasons for technical debt will continue- why not plan to > > service the debt regularly? > > If we go ahead and skip the F31 release, I see this as a (perhaps > necessary) desperation move - there is a small group of a dozen or so > people who would be key to improving our release processes, but those > people are always busy making releases. > > But for the next thousand or so Fedora developers, the release cycle > is actually not a big deal - not something that takes much of their > time - and it gives them a regular place to land feature work. And > Fedora users appreciate a timely updated operating system (without > having random rebases trickle in.) It's not a big deal because they don't participate in making the release nor do they really know about all the duct tape and bailing wire holding all the machinery in place. Just like most of them don't appreciate the heroics involved from Fedora QA and rel-eng and the dozen or so people that regularly go well beyond the extra mile to get it out the door. This isn't done out of malice on their part. It's mostly that they just don't see it. > In other words, the "technical debt" we are trying to solve here is > not project wide and doesn't justify slowing down the whole project > permanently. I completely disagree. Our release process and tooling is built on heroism and tech debt. At some point, that is going to cause significant burnout and then people will just wonder what happened when those people stop doing releases. I think it's better to raise awareness at the project level, and build something that is sustainable rather than predicated on "small group of people killing themselves for the greater good". That starts with individual package CI gating, and goes all the way through integration testing between packages in a gated manner, into how we actually *create* all of that plus the things we deem worth of releasing. josh _______________________________________________ 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
