Neal Gompa píše v St 14. 11. 2018 v 07:54 -0500: > On Wed, Nov 14, 2018 at 7:49 AM Kalev Lember <kalevlember@xxxxxxxxx> > wrote: > > On 11/14/2018 11:35 AM, Daniel P. Berrangé wrote: > > > If Fedora had longer life cycles, and more streams maintained in > > > parallel, then I think the result would be that I end up doing > > > rebases for everything I maintain rather than trying to backport > > > anything. Admittedly this would somewhat negate the supposed > > > benefit > > > of having stable long life releases, but its either that or the > > > releases bitrot accumulating more & more bugs & security flaws. > > > > I agree, this would lead to too much workload on the maintainers if > > we > > just add a new long-lived branch. There's already rawhide, F29, > > F28, F27 > > which is already quite a lot of branches to maintain. > > > > However, I think this could work if we change how long we maintain > > the > > non-LTS branches. > > > > If we reduce the non-LTS supported time from 13 months to, let's > > say, 7 > > months (2 months overlap to allow for time to upgrade) then perhaps > > it > > could work? And then add a LTS branch that's supported for 3 years? > > We'd > > have the same number of branches as now, just that one is LTS. > > > > That's basically the Ubuntu model. They do 9 months for regular > releases, and 5 years (originally 3 years) for LTS releases. > > However, what could also work would be something along the lines of > openSUSE Evergreen[1] model (prior to the shift to openSUSE Leap + > Tumbleweed), where the community decides on a version to stabilize > and > maintain for bugfixes for an extended period of time. If we wanted to > talk about having extended lifecycles, I think this would be a > workable model. This would be similar to the original Fedora Legacy > project (if anyone remembers that!). That's my thinking, too. Having releases supported for 7 months is not really worth it, let's rather switch to a stable rolling release for those who want the latest and greatest. LTS will be there for the rest. And the rolling release version can also serve as a stream of apps for LTS releases. We can build the latest Firefox with the latest stable Fedora bits and provide it on LTS releases as a flatpak. A single build for all releases. The model may actually even be easier for maintainers. Jiri _______________________________________________ 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
