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(a)gmail.com>
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