On Mon, Nov 26, 2018 at 9:27 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? > I'm going to have a longer post to reply about the overall topic brought up over Turkey Day, but for this specific point, I think that it would be a tremendous mistake if we allowed RHEL to influence us into slowing down the core of Fedora (see, I said the "bad" word!). In the past few years, I've been around the block a bit, being involved in different distribution release philosophies and processes. And one thing that is common among all of them is that "stuff rolls downstream". That is, an action from the top part usually has cascading effects downward. Most of us don't consider the "core"/"base platform" of Fedora to be the "top", but it is. All the decisions about how every package is built and shipped is affected by this. It would be incredibly dangerous for Fedora to take a RHEL-like approach to the core, because it means that we're deciding that the core is not a place for innovation and advancement. Now, I'll admit I have a personal stake here: much of what *I* do these days is in that part of the stack, and having that frozen would kill my ability to participate in the development of the distribution. But I'd like us to become less conservative instead of more so. I've been playing with the RHEL 8 beta for a bit now, and I have a pretty good idea what constitutes a "base" system in RHEL, and I'm afraid that it would be terrible if we froze that for a year. However, to the larger point about lifecycles and supporting hardware makers with a Fedora LTS that works for 4 years, this could be a good focus point for a new "Fedora Long-Term" WG that would work to take selected releases of Fedora and stabilize them for a period of time. This would be similar to the original Fedora Legacy and openSUSE Evergreen[1] projects. An interesting twist here is that we could take some inspiration from Debian on how they run their LTS and allow direct sponsorship for releases to be supported past their original life[2]. That means that under the auspices of the Fedora Project, interested volunteers and commercial entities could come together and maintain a release with security fixes past the 13 month life, for an additional 2 years. This approach has some advantages: notably only releases people are interested it would qualify, and the work burden scales with interest and sponsorship. The main disadvantage is that it won't happen "for free", which I think is actually a good thing here. Even Red Hat could participate in this program, though I fully expect that they won't, since they have their hands full with Red Hat Enterprise Linux. But it'd be nice if they did, because it could also be an avenue to improve the transparency between Fedora and RHEL, and give a more direct relationship (and potential for influencing improvements to RHEL that we don't have today!). It would also make it easier for the 22 other product projects that Red Hat has to use Fedora as their upstream rather than CentOS, since some folks in those communities complain Fedora is too fast for them (*hack*RDO*cough*). [1]: https://en.opensuse.org/openSUSE:Evergreen [2]: https://wiki.debian.org/LTS/ -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
