Fedora Lifecycles: imagine longer-term possibilities

[Matthew Miller]

Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk about how we might address
some of the users and use cases we're missing out on.

When I talk to people about this, I often get "hey, you should do LTS
or go to rolling releases.” As I've said before, on the surface that's
a weird thing to say, since the actual user impact of those two
different things is mostly _opposite_. So, digging in, it often really
means "I don't want the pain and fear of big OS upgrades".

We've addressed that in several ways: first, making upgrades better.
(Thanks everyone who has worked on that.) A Fedora release-to-release
update is normally not much more trouble than you might get some random
Tuesday with a rolling release. Second, we have some things like Fedora
Atomic Host and upcoming Fedora CoreOS and IoT which both implement a
rolling stream on top of the Fedora release base. And finally, there's
the coming-someday plans for gating Rawhide, making that a better
proposition for people who really want to live on the edge.

But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.

So, what would this look like? I have some ideas, but, really, there
are many possibilities. That's what this thread is for. Let's figure it
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?




--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists

[Stephen John Smoogen]

Post by Matthew Miller
Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk about how we might address
some of the users and use cases we're missing out on.
When I talk to people about this, I often get "hey, you should do LTS
or go to rolling releases.” As I've said before, on the surface that's
a weird thing to say, since the actual user impact of those two
different things is mostly _opposite_. So, digging in, it often really
means "I don't want the pain and fear of big OS upgrades".
We've addressed that in several ways: first, making upgrades better.
(Thanks everyone who has worked on that.) A Fedora release-to-release
update is normally not much more trouble than you might get some random
Tuesday with a rolling release. Second, we have some things like Fedora
Atomic Host and upcoming Fedora CoreOS and IoT which both implement a
rolling stream on top of the Fedora release base. And finally, there's
the coming-someday plans for gating Rawhide, making that a better
proposition for people who really want to live on the edge.
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.
So, what would this look like? I have some ideas, but, really, there
are many possibilities. That's what this thread is for. Let's figure it
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?

There are a lot of possibilities, but it is also that "something that
lasts for 36-48 months" probably means something different to everyone
involved.

To some set it means "Whatever was shipped on Day0 had only better get
backported fixes and maybe, maybe minor updates", to others it means
"well it shouldn't have any major api/abi updates in those 36-48
months.. " to the "so this just means it should be a rolling update as
long as everything always works or resets easily". Is this
conversation completely blue-sky or are there boundaries we should
watch out for so we aren't arguing over "well why not make Fedora a
rebuild of Debian using a deb2rpm tool since they already are LTS" and
other people saying why not <fill in other LTS distro here>


--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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

[Matthew Miller]

Post by Stephen John Smoogen

Post by Matthew Miller
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.

[...]

Post by Stephen John Smoogen
There are a lot of possibilities, but it is also that "something that
lasts for 36-48 months" probably means something different to everyone
involved.
To some set it means "Whatever was shipped on Day0 had only better get
backported fixes and maybe, maybe minor updates", to others it means
"well it shouldn't have any major api/abi updates in those 36-48
months.. " to the "so this just means it should be a rolling update as
long as everything always works or resets easily". Is this
conversation completely blue-sky or are there boundaries we should
watch out for so we aren't arguing over "well why not make Fedora a
rebuild of Debian using a deb2rpm tool since they already are LTS" and
other people saying why not <fill in other LTS distro here>

Mostly blue sky -- let's generate ideas! -- but let's also stay within
reasonable possibilities, and also, you know, keeping it Fedora.
Particularly, I'm pretty sure about the goals: 1. getting Fedora desktop and
IoT shipped on systems and 2. expanding the community by getting Fedora into
places which don't consider us because we're perceived as too fleeting.


--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedo

[Iñaki Ucar]

Post by Matthew Miller
Mostly blue sky -- let's generate ideas! -- but let's also stay within
reasonable possibilities, and also, you know, keeping it Fedora.
Particularly, I'm pretty sure about the goals: 1. getting Fedora desktop and
IoT shipped on systems and 2. expanding the community by getting Fedora into
places which don't consider us because we're perceived as too fleeting.

Why not make just IoT LTS?

--
Iñaki Úcar
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorapro

[Matthew Miller]

Post by Iñaki Ucar

Post by Matthew Miller
Mostly blue sky -- let's generate ideas! -- but let's also stay within
reasonable possibilities, and also, you know, keeping it Fedora.
Particularly, I'm pretty sure about the goals: 1. getting Fedora desktop and
IoT shipped on systems and 2. expanding the community by getting Fedora into
places which don't consider us because we're perceived as too fleeting.

Why not make just IoT LTS?

That's a possibility. How would we do that?

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/lis

[Iñaki Ucar]

Post by Matthew Miller

Post by Iñaki Ucar

Post by Matthew Miller
Mostly blue sky -- let's generate ideas! -- but let's also stay within
reasonable possibilities, and also, you know, keeping it Fedora.
Particularly, I'm pretty sure about the goals: 1. getting Fedora

desktop and

Post by Iñaki Ucar

Post by Matthew Miller
IoT shipped on systems and 2. expanding the community by getting

Fedora into

Post by Iñaki Ucar

Post by Matthew Miller
places which don't consider us because we're perceived as too fleeting.

Why not make just IoT LTS?

That's a possibility. How would we do that?

IoT has quite particular requirements. Ubuntu Core was made with that in
mind and, AFAIK, it's a complete different thing.

Iñaki

[Michal Schorm]

We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.

That allow us to manage changes like GCC, OpenSSL and so on quickly.
Struggling with upstream who don't adapt, can't adapt or don't want to
adapt at the same speed. (And OpenSSL patch isn't something you'd want
to write for serveral pojects you maintain ...)

That is what make us different distro with its own user base. Want the
very same but LTS system? try CentOS. Or RHEL.
--
Speaking for myslef, the trouble is to keep up with the system wide
changes even as a maintainer.
The MariaDB package for example:
In just last two years it went though 4 major releases - from 10.0 to 10.3.
I put a big effort into dividing server and client part, changing
packages layout and build dependency tree (for packages which need
MariaDB).
MariaDB also re-writtent the whole client library, huge change again.
Than OpenSSL, new GCC, python 2 removal ...
With so much changing, imagine the anguish of upgrades.

Last half a year I tried to make COPR repositories for each major
release (10.1-10.3) for every Fedora version (F27+). Worked well with
"15 minutes of best effort" rule. Not sure if anybody used it though.
Now I can slowly abadon the COPR thanks to modules which does the
trick. However all of the problems remained, while I should put more
energy and time into it.
* Rebuild 10.1 with new OpenSSL? don't think so ...
* Change package layout to undo some changes in releases that don
support it? not compatible with the rest of the OS ...
* Use release with old client library in Fedora version adjusted to
new one? breaks literaly everything ...

It's like "give me another folk working full time on it and I still
don't believe we could solve all of this".

What I wanted to express by this message is the fact, prolonging
software support time in Fedora means *a lot* of low-level work TBD.
I can maintain it either "bleeding edge style", geting users new
features literally ASAP, or "LTS style" defend the database from any
update to not break anything, bugfix and security fix only. (I'm doing
it for RHEL after all).
But not both.
That would require wide matrix of versions adapted to every change,
update and feature or not adapted at all (or just to some of them);
depending on whether the specific user pick LTS version or evolving
one.

Looked for a solution for over a year. Not finding any.
I keep saying RHEL & CentOS are our LTS versions.
Wishing good luck to your search.
--
Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat
--
On Wed, Nov 14, 2018 at 12:37 AM Matthew Miller

Post by Matthew Miller
Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk about how we might address
some of the users and use cases we're missing out on.
When I talk to people about this, I often get "hey, you should do LTS
or go to rolling releases.” As I've said before, on the surface that's
a weird thing to say, since the actual user impact of those two
different things is mostly _opposite_. So, digging in, it often really
means "I don't want the pain and fear of big OS upgrades".
We've addressed that in several ways: first, making upgrades better.
(Thanks everyone who has worked on that.) A Fedora release-to-release
update is normally not much more trouble than you might get some random
Tuesday with a rolling release. Second, we have some things like Fedora
Atomic Host and upcoming Fedora CoreOS and IoT which both implement a
rolling stream on top of the Fedora release base. And finally, there's
the coming-someday plans for gating Rawhide, making that a better
proposition for people who really want to live on the edge.
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.
So, what would this look like? I have some ideas, but, really, there
are many possibilities. That's what this thread is for. Let's figure it
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?
--
Matthew Miller
Fedora Project Leader
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorap

[Zbigniew Jędrzejewski-Szmek]

Post by Michal Schorm
We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.
That allow us to manage changes like GCC, OpenSSL and so on quickly.
Struggling with upstream who don't adapt, can't adapt or don't want to
adapt at the same speed. (And OpenSSL patch isn't something you'd want
to write for serveral pojects you maintain ...)
That is what make us different distro with its own user base. Want the
very same but LTS system? try CentOS. Or RHEL.

+1

As can be clearly seen from the breadth of the update streams, once F+2
is released, F+1 still gets a moderate number of updates, but F only
gets major bugs fixed, at best. Some maintainers care more, some less,
but it's pretty obvious that our "oldstable" release is not where the
maintainers are. Now imagine how well we would support F-4 (36 months)
or F-6 (48 months). I'd guess "not at all".

I don't see this going anywhere without a lot of new maintainers.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/archiv

[Daniel P. Berrangé]

Post by Zbigniew Jędrzejewski-Szmek

Post by Michal Schorm
We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.
That allow us to manage changes like GCC, OpenSSL and so on quickly.
Struggling with upstream who don't adapt, can't adapt or don't want to
adapt at the same speed. (And OpenSSL patch isn't something you'd want
to write for serveral pojects you maintain ...)
That is what make us different distro with its own user base. Want the
very same but LTS system? try CentOS. Or RHEL.

+1
As can be clearly seen from the breadth of the update streams, once F+2
is released, F+1 still gets a moderate number of updates, but F only
gets major bugs fixed, at best. Some maintainers care more, some less,
but it's pretty obvious that our "oldstable" release is not where the
maintainers are. Now imagine how well we would support F-4 (36 months)
or F-6 (48 months). I'd guess "not at all".

It is not so much whether we "care", but rather whether we have enough
time in the day to get the expected work done. I can't magic up more
time to work no matter how much I care to.

Even with the current lifecycle, once a new stable Fedora release comes
out, I'll usually only backport security fixes to the previous stable
Fedora release from that time onwards. Any other bugs will only get
addressed in the most recent stable release unless its trivial to do
the previous one too. In some cases I'll not even pretend to be able
to backport, and instead simply rebase all existing Fedora releases
to latest upstream versions every time.

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.


Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/dev

[Kalev Lember]

Post by Daniel P. Berrangé
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.

--
Kalev
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/dev

[Neal Gompa]

Post by Kalev Lember

Post by Daniel P. Berrangé
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!).

[1]: https://en.opensuse.org/openSUSE:Evergreen


--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/archive

[Matthew Miller]

Post by Neal Gompa

Post by Kalev Lember
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!).
[1]: https://en.opensuse.org/openSUSE:Evergreen

Yeah I came into Fedora through the Legacy project. :)

There are also ideas from Tom Callaway's proposal from FUDCon Lawrence: a
major release every two years, followed by point updates. Kind of like RHL
back in the day.


--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproje

[Jiri Eischmann]

Post by Neal Gompa

Post by Kalev Lember

Post by Daniel P. Berrangé
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 -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lis

[Matthew Miller]

Post by Jiri Eischmann
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.

I think the very, very high fast rate I'm seeing in the mirror stats (see
https://twitter.com/mattdm/status/1063058469903839232) recently supports the
idea of a rolling release to cater to a lot of our audience. I wouldn't
necessarily have said that three years ago -- look at the upgrade curve for
f23 at the left side of the graph.



--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/l

[Matthew Miller]

Post by Matthew Miller
I think the very, very high fast rate I'm seeing in the mirror stats (see

Too excited! "Very high fast upgrade rate." :)

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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

[Richard Hughes]

Post by Daniel P. Berrangé
It is not so much whether we "care", but rather whether we have enough
time in the day to get the expected work done. I can't magic up more
time to work no matter how much I care to.

Exactly my situation too.

Richard.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/deve

[Laura Abbott]

Post by Daniel P. Berrangé
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.

At least for the kernel, if we actually had a Fedora LTS we could
do the opposite of what we have now which is rebase as soon as the
kernel releases. The kernel already has LTS releases available which
are nominally maintained for two years (c.f. https://www.kernel.org/category/releases.html).
Because of the timing of the kernel releases (about every 90 days)
we just end up rebasing within a Fedora release because there usually
isn't time to try and pick an LTS kernel to use. An actual Fedora
LTS would mean we could potentially align to what LTS kernel upstream
chooses.

More generally though, this makes sense for the kernel because that
project already thinks about LTS. If a project doesn't already have
a well defined LTS release then I suspect many packagers will just
end up rebasing because it's more comprehensive.

Thanks,
Laura
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproj

[Samuel Rakitničan]

Post by Zbigniew Jędrzejewski-Szmek
As can be clearly seen from the breadth of the update streams, once F+2
is released, F+1 still gets a moderate number of updates, but F only
gets major bugs fixed, at best. Some maintainers care more, some less,
but it's pretty obvious that our "oldstable" release is not where the
maintainers are. Now imagine how well we would support F-4 (36 months)
or F-6 (48 months). I'd guess "not at all".
I don't see this going anywhere without a lot of new maintainers.
Zbyszek

How about keeping the number of supported releases the same, just change the support window for them. For example have one release that is supported for 6 months, and then have one release that is supported for longer.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/archi

[Matthew Miller]

Post by Michal Schorm
We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.

But being "bleeding edge" has never been what Fedora's about, despite
getting that epithet slapped at us. Yes, we want innovation and new
software, but we also want software which *works*. We want to provide a
consistent, pleasant, and functional user experience, without getting
metaphorical blood all over.


[...]

Post by Michal Schorm
What I wanted to express by this message is the fact, prolonging
software support time in Fedora means *a lot* of low-level work TBD.
I can maintain it either "bleeding edge style", geting users new
features literally ASAP, or "LTS style" defend the database from any
update to not break anything, bugfix and security fix only. (I'm doing
it for RHEL after all).
But not both.

Lots of good feedback, but I want to focus on this last comment.

It sounds like you are actually already doing both approaches -- the fast
branch for Fedora and a slower, RH-internal branch for RHEL. What if you
made that slower branch *also* in Fedora as a direct upstream for your
internal RHEL work? Fedora is supposed to be the upstream for RHEL, after
all. Why not make that true all of the time, not just every N years when
RHEL branches?


--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject.or

[Zbigniew Jędrzejewski-Szmek]

Post by Matthew Miller

Post by Michal Schorm
We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.

But being "bleeding edge" has never been what Fedora's about, despite
getting that epithet slapped at us. Yes, we want innovation and new
software, but we also want software which *works*. We want to provide a
consistent, pleasant, and functional user experience, without getting
metaphorical blood all over.
[...]

Post by Michal Schorm
What I wanted to express by this message is the fact, prolonging
software support time in Fedora means *a lot* of low-level work TBD.
I can maintain it either "bleeding edge style", geting users new
features literally ASAP, or "LTS style" defend the database from any
update to not break anything, bugfix and security fix only. (I'm doing
it for RHEL after all).
But not both.

Lots of good feedback, but I want to focus on this last comment.
It sounds like you are actually already doing both approaches -- the fast
branch for Fedora and a slower, RH-internal branch for RHEL. What if you
made that slower branch *also* in Fedora as a direct upstream for your
internal RHEL work? Fedora is supposed to be the upstream for RHEL, after
all. Why not make that true all of the time, not just every N years when
RHEL branches?

Because each old version is different? The fact that a backport has
been made for RHEL does not mean that this backport is appropriate for
the given Fedora version. Iff this was so simple, we could just take
CentOS packages and compile them for Fedora.

In my experience, backporting even to older version of Fedora is
proportional to the number of branches. This is because the diff between
F-2 and F-1 is just as large (on average) as the diff between F-1 and F.

(That was the technical consideration. There's also the social side:
working on new&shiny that you use yourself is fun, doing the same for
old and stable versions is a job.)

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/de

[Matthew Miller]

Post by Zbigniew Jędrzejewski-Szmek
Because each old version is different? The fact that a backport has
been made for RHEL does not mean that this backport is appropriate for
the given Fedora version. Iff this was so simple, we could just take
CentOS packages and compile them for Fedora.

Well, in a lot of cases, we *could*.

Post by Zbigniew Jędrzejewski-Szmek
In my experience, backporting even to older version of Fedora is
proportional to the number of branches. This is because the diff between
F-2 and F-1 is just as large (on average) as the diff between F-1 and F.

Yeah, definitely. We can't do this in a way which significantly increases
the number of active branches.


--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraprojec

[Gerald Henriksen]

Post by Michal Schorm
We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.

Such a bleeding edge distro that it took 4 years for Swift to arrive,
or still trying to get rid of Python 2.

Regardless of what we think Fedora is or isn't, a look outside of
Fedora shows an overall Linux community that appears to be
increasingly ignoring Fedora.

Part of this discussion needs to be around the combined issues of
getting more maintainers and getting more users.

My feeling is part of the solution is to move to a yearly release
cycle. Unlike the early days of Fedora things just aren't changing as
quick in terms of the base of the OS - hardware support in the kernel
is generally excellent, and both Gnome and KDE (and likely the others)
are mature environments that while they improve with each release
there isn't generally anything that says a 6 month wait would be
unbearable - and consideration should also be done to the track record
that given the overall stability of those desktops that upgrades can
likely be done safely mid-Fedora-release.

So perhaps then you go with 2 effective releases of Fedora - a one
year release, and a 3 year release. You get the benefits for those
that need it of a LTS style product, reduce the upgrade churn that is
putting off some prospective users. Won't satisfy everyone but it may
be an improvement.

Anything that really can't wait for a next release could be
temporarily thrown into COPR, with perhaps a feature that at the next
major release the COPR repository automatically gets removed as the
package is now available from the main Fedora repository.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject.

[Ralf Corsepius]

Post by Gerald Henriksen

Post by Michal Schorm
We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.

Such a bleeding edge distro that it took 4 years for Swift to arrive,
or still trying to get rid of Python 2.

Fedora has become "bleeding edge" in sense of being unstable, unreliable
and containing immature, experimental features.

Post by Gerald Henriksen
Regardless of what we think Fedora is or isn't, a look outside of
Fedora shows an overall Linux community that appears to be
increasingly ignoring Fedora.

Absolutely. Fedora once was a pretty solid end-user distro and
fun-project for devs. Now it has become an unstable, experimental
"bleeding edge" distro with a more and more balloning overhead.

Post by Gerald Henriksen
Part of this discussion needs to be around the combined issues of
getting more maintainers and getting more users.
My feeling is part of the solution is to move to a yearly release
cycle.

This would be my proposal, also. I would simply extend the release
cycles to 1 year and to return to the roots. I.e. make a distro, and
drop "rings" "modules" and "spins".

Ralf
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedor

[m***@gnome.org]

Post by Ralf Corsepius
Absolutely. Fedora once was a pretty solid end-user distro and
fun-project for devs. Now it has become an unstable, experimental
"bleeding edge" distro with a more and more balloning overhead.

I don't agree at all. Fedora is great. We have tons of compliments from
users in places like /r/Fedora and /r/GNOME praising how stable Fedora
is. We have by far the most developers working on the distro, thanks to
Red Hat. And our QA process -- blocker bugs and freeze exceptions -- is
second to none, and ensures we have the highest-quality product of any
comparable distro on release day.

What we have is a reputation management issue. This reputation that
Fedora is bleeding edge or a testbed for RHEL is pervasive, and we need
to find some way to kill it.

Another issue is that our updates QA remains insufficient: broken
updates are able to reach users before they can be detected and pulled,
defeating the benefit of all that release day QA. Subjectively, this
situation feels better nowadays than it used to be. But we still had a
big problem with the recent broken mesa and GCC updates, for example.

Michael

[Stephen John Smoogen]

Absolutely. Fedora once was a pretty solid end-user distro and fun-project for devs. Now it has become an unstable, experimental "bleeding edge" distro with a more and more balloning overhead.
I don't agree at all. Fedora is great. We have tons of compliments from users in places like /r/Fedora and /r/GNOME praising how stable Fedora is. We have by far the most developers working on the distro, thanks to Red Hat. And our QA process -- blocker bugs and freeze exceptions -- is second to none, and ensures we have the highest-quality product of any comparable distro on release day.
What we have is a reputation management issue. This reputation that Fedora is bleeding edge or a testbed for RHEL is pervasive, and we need to find some way to kill it.

You can't kill 'bleeding edge' without understanding what 'bleeding
edge' means to the person saying it. For a LOT of the people who call
Fedora bleeding edge, they look at the fact that we rebase GNOME twice
a year and a bunch of other things and to them that means bleeding
edge. It doesn't mean that for you, but it does for them. Telling them
that Fedora isn't bleeding edge when it is quite obvious to them that
it is just comes across as trying to blow smoke up .. Outside of the
community of innovative developers that Linux attracts, the plurality
of computer users still think that Windows 7 is fine enough for them.
Inside Linux users, most of them are just liking the GNOME and KDE you
just stopped supporting. Anything other than that is bleeding edge to
them. We might call it cutting edge or other terms to give nuance..
but most people just use bleeding edge for anything which isn't
sitting still for 2-3 years.

The same goes for testbed. Fedora is a testbed for RHEL in the same
way that Debian is a testbed for Ubuntu. It doesn't matter that is
silly to us.. most people who are not spending their days in the guts
of the machine of distribution making are going to lump it that way.
And once it is lumped that way... it is the reputation that sticks.
You can spend hours trying to explain it over and over and come back 2
days later and find the people you talked to have gone back to the
same items. The brain is a very complicated neural net where
reputations are local minima in the storage and to get an idea moved
from one place or another takes a lot of continual energy to push the
idea from one reputation to another.


--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject.org

[Daniel P. Berrangé]

Post by Gerald Henriksen

Post by Michal Schorm
We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.

Such a bleeding edge distro that it took 4 years for Swift to arrive,
or still trying to get rid of Python 2.

Fedora has become "bleeding edge" in sense of being unstable, unreliable and
containing immature, experimental features.

IME the opposite has happened - I see far less instability and
breakage when upgrading to a new Fedora release these days, than
experienced in the past. Even rawhide doesn't destroy systems
as frequently as it did in the past.

Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fed

[Kevin Kofler]

Post by Ralf Corsepius
This would be my proposal, also. I would simply extend the release
cycles to 1 year and to return to the roots. I.e. make a distro, and
drop "rings" "modules" and "spins".

Rings and modules should go away indeed, but spins should not! We have had
spins since Fedora 7! They are part of the success story of Fedora.

What should be dropped, though, is the artificial distinction between
"editions" and "spins". Everything should be an equally-featured spin, and
the GNOME spin should be called GNOME spin.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject.org

[John Florian]

I concur. This is effectively what I was trying to express with respect to the distinctions.

Post by Kevin Kofler

Post by Ralf Corsepius
This would be my proposal, also. I would simply extend the release
cycles to 1 year and to return to the roots. I.e. make a distro, and
drop "rings" "modules" and "spins".

Rings and modules should go away indeed, but spins should not! We have had
spins since Fedora 7! They are part of the success story of Fedora.
What should be dropped, though, is the artificial distinction between
"editions" and "spins". Everything should be an equally-featured spin, and
the GNOME spin should be called GNOME spin.
Kevin Kofler
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

[Martin Jackson]

I think different people want different things from an LTS though. CentOS makes it hard to do e.g. Postgres 10 and Python3 which Ubuntu ships out of the box in 1804. Modularity seems like it will help in this regard.

Post by Kevin Kofler

Post by Ralf Corsepius
This would be my proposal, also. I would simply extend the release
cycles to 1 year and to return to the roots. I.e. make a distro, and
drop "rings" "modules" and "spins".

Rings and modules should go away indeed, but spins should not! We have had
spins since Fedora 7! They are part of the success story of Fedora.
What should be dropped, though, is the artificial distinction between
"editions" and "spins". Everything should be an equally-featured spin, and
the GNOME spin should be called GNOME spin.
Kevin Kofler
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject.or

[m***@gnome.org]

Post by Gerald Henriksen
My feeling is part of the solution is to move to a yearly release
cycle. Unlike the early days of Fedora things just aren't changing as
quick in terms of the base of the OS - hardware support in the kernel
is generally excellent, and both Gnome and KDE (and likely the others)
are mature environments that while they improve with each release
there isn't generally anything that says a 6 month wait would be
unbearable - and consideration should also be done to the track record
that given the overall stability of those desktops that upgrades can
likely be done safely mid-Fedora-release.

We need to rebase GNOME within about two months of the new upstream
releases, or we'll lose our edge with the GNOME community. We'd be
ceding our position as best GNOME distro to Ubuntu and Arch. So a
one-year cycle means a major GNOME version update will need to land in
the middle of a release to avoid that. And these do not have a good
reputation for stability. Basically we'll wind up with a bunch of bugs
landing halfway through the release, and without the usual Fedora QA
process to ensure the most important of them get fixed before they
reach users. So I can't support this plan....

Michael

[Matthew Miller]

Post by m***@gnome.org
We need to rebase GNOME within about two months of the new upstream
releases, or we'll lose our edge with the GNOME community. We'd be
ceding our position as best GNOME distro to Ubuntu and Arch. So a
one-year cycle means a major GNOME version update will need to land
in the middle of a release to avoid that. And these do not have a
good reputation for stability. Basically we'll wind up with a bunch
of bugs landing halfway through the release, and without the usual
Fedora QA process to ensure the most important of them get fixed
before they reach users. So I can't support this plan....

Is there a way we could do these as ".1" releases, with orchestrated QA for
the big update rather than a whole release?

Or, if we can combine this with having a gated Rawhide meant for day-to-day
use (and using ostree for rollbacks), would that be adequate for the "on the
edge" GNOME community?



--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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.or

[m***@gnome.org]

On Wed, Nov 14, 2018 at 10:31 AM, Matthew Miller

Post by Matthew Miller
Is there a way we could do these as ".1" releases, with orchestrated QA for
the big update rather than a whole release?

It's a possibility... I'd rather call it .5 for halfway, though.

F30, F30.5, F31... ehh, it would be OK, but there should be real
concrete gain if we do this. It gets us no closer to a 36 month
lifetime.

Post by Matthew Miller
Or, if we can combine this with having a gated Rawhide meant for day-to-day
use (and using ostree for rollbacks), would that be adequate for the "on the
edge" GNOME community?

No, even I wouldn't use it. I like having a stable desktop.

Michael

[Matthew Miller]

Post by m***@gnome.org
It's a possibility... I'd rather call it .5 for halfway, though.
F30, F30.5, F31... ehh, it would be OK, but there should be real
concrete gain if we do this. It gets us no closer to a 36 month
lifetime.

Well, it would reduce the number of active streams, and make the QA effort
be a subset of full-release QA.

Alternately, GNOME could switch to a yearly release cycle for our
convenience. :)

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/a

[John Florian]

Post by m***@gnome.org
We need to rebase GNOME within about two months of the new upstream
releases, or we'll lose our edge with the GNOME community. We'd be
ceding our position as best GNOME distro to Ubuntu and Arch.

It seems wrong that a DE, even if it's the default, has so much sway
over the distro as a whole.  I use Fedora for so much more than a
desktop.  Admittedly, I've never been a big fan of spins and would much
prefer to see all DEs and other spin-like things just be more rpms I can
install, if I choose ... all on top of a single base OS.

Post by m***@gnome.org
So a one-year cycle means a major GNOME version update will need to
land in the middle of a release to avoid that. And these do not have a
good reputation for stability. Basically we'll wind up with a bunch of
bugs landing halfway through the release, and without the usual Fedora
QA process to ensure the most important of them get fixed before they
reach users.

Why can't GNOME be updated mid-release like any other application?  Why
does the QA process require the cadence of the whole distro release
process to bend to GNOME?  Can't a major GNOME update land in the
testing repos to have QA issues sorted out there just as well as in some
alpha/beta release of the overall Fedora?

I would think that the distro release cadence only have hard limits set
by things like the kernel and glibc.  I'm probably taking an entirely
too simple view of the overall process and am not attacking GNOME
specifically, but just as an example given your comment.  I'm just
genuinely trying to understand the reasoning behind it and see if those
assumptions cannot be changed.

I'd love to see Fedora move to a one year release, but with a 6 month
upgrade period (N and N-1 for 6 months vs the present N, N-1 and N-2 for
1 month).  I'd think that would mean less work for maintainers and
provide nearly the same or better benefit to users as what we have now.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@list

[Zbigniew Jędrzejewski-Szmek]

Post by John Florian

Post by m***@gnome.org
We need to rebase GNOME within about two months of the new
upstream releases, or we'll lose our edge with the GNOME
community. We'd be ceding our position as best GNOME distro to
Ubuntu and Arch.

It seems wrong that a DE, even if it's the default, has so much sway
over the distro as a whole.

It's not just gnome. It's also gcc, glibc, boost, systemd, python, and
any other project which cannot be upgraded easily mid-cycle. Having
a chance to push a new version every six months is much better than
waiting a year.

Post by John Florian

Post by m***@gnome.org
So a one-year cycle means a major GNOME version update will need
to land in the middle of a release to avoid that. And these do not
have a good reputation for stability. Basically we'll wind up with
a bunch of bugs landing halfway through the release, and without
the usual Fedora QA process to ensure the most important of them
get fixed before they reach users.

Why can't GNOME be updated mid-release like any other application? 
Why does the QA process require the cadence of the whole distro
release process to bend to GNOME?  Can't a major GNOME update land
in the testing repos to have QA issues sorted out there just as well
as in some alpha/beta release of the overall Fedora?

For me, any discussions about .1 or .5 completely miss the point.
The numbering does not matter at all, the freeze and the testing and
bugfixing matters. If we do it every 6 months, we might just as well
call this a new release each time.

As mentioned elsewhere in this thread, we have plenty of technical
issues to solve, including security bugs and whatnot. Let's not get
distracted by numbering.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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.

[John Florian]

Post by Zbigniew Jędrzejewski-Szmek

Post by John Florian

Post by m***@gnome.org
We need to rebase GNOME within about two months of the new
upstream releases, or we'll lose our edge with the GNOME
community. We'd be ceding our position as best GNOME distro to
Ubuntu and Arch.

It seems wrong that a DE, even if it's the default, has so much sway
over the distro as a whole.

It's not just gnome. It's also gcc, glibc, boost, systemd, python, and
any other project which cannot be upgraded easily mid-cycle. Having
a chance to push a new version every six months is much better than
waiting a year.

I still don't understand what makes updating these for a *new* release
significantly easier than an *existing* one.  So let's just say GNOME
(or whatever) comes out next month with a new major release we want to
showcase.  Why is it necessary to have a Fedora 30 to be able to realize
this update.  What is so difficult about providing this for Fedora 29. 
I'm trying to understand why these upstream updates can't be decoupled
from the Fedora release schedule.

Post by Zbigniew Jędrzejewski-Szmek

Post by John Florian

Post by m***@gnome.org
So a one-year cycle means a major GNOME version update will need
to land in the middle of a release to avoid that. And these do not
have a good reputation for stability. Basically we'll wind up with
a bunch of bugs landing halfway through the release, and without
the usual Fedora QA process to ensure the most important of them
get fixed before they reach users.

Why can't GNOME be updated mid-release like any other application?
Why does the QA process require the cadence of the whole distro
release process to bend to GNOME?  Can't a major GNOME update land
in the testing repos to have QA issues sorted out there just as well
as in some alpha/beta release of the overall Fedora?

For me, any discussions about .1 or .5 completely miss the point.
The numbering does not matter at all, the freeze and the testing and
bugfixing matters. If we do it every 6 months, we might just as well
call this a new release each time.
As mentioned elsewhere in this thread, we have plenty of technical
issues to solve, including security bugs and whatnot. Let's not get
distracted by numbering.

I agree the numbering is irrelevant... I never said it was.  It was said
or implied that QA works better *between* releases and I don't see why
that cannot occur for a release that's already out the door.  I mean
isn't that what the testing repos are for?  So I'm proposing to partly
evolve to a sort of rolling distro.  If the schedule decoupling can
occur, it should then be possible to move Fedora to a yearly release
schedule, provide a 6 month upgrade window and reduce maintainer burden
because there's only 1 or 2 supported releases instead of 2 or 3.  That
would mean releases are supported for 18 months instead of 13.  Change
the periods how you wish, but the decoupling would allow getting longer
support while requiring less work due to fewer concurrent releases.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/arc

[Kevin Fenzi]

Post by John Florian
I still don't understand what makes updating these for a *new* release
significantly easier than an *existing* one.  So let's just say GNOME
(or whatever) comes out next month with a new major release we want to
showcase.  Why is it necessary to have a Fedora 30 to be able to realize
this update.  What is so difficult about providing this for Fedora 29. 
I'm trying to understand why these upstream updates can't be decoupled
from the Fedora release schedule.

Well, there's the problem all rolling releases have with that:
The user (mostly) has to accept changes when the distro pushes them.
If you push major updates at release boundries, users can choose to stay
on the older release until they are ready to devote time to the upgrade.

Some users are fine with change any old time and adapt, but others
dislike that to varying degrees.

kevin

[Brian (bex) Exelbierd]

Post by Kevin Fenzi

Post by John Florian
I still don't understand what makes updating these for a *new* release
significantly easier than an *existing* one. So let's just say GNOME
(or whatever) comes out next month with a new major release we want to
showcase. Why is it necessary to have a Fedora 30 to be able to realize
this update. What is so difficult about providing this for Fedora 29.
I'm trying to understand why these upstream updates can't be decoupled
from the Fedora release schedule.

The user (mostly) has to accept changes when the distro pushes them.
If you push major updates at release boundries, users can choose to stay
on the older release until they are ready to devote time to the upgrade.
Some users are fine with change any old time and adapt, but others
dislike that to varying degrees.

I understand this argument, but I think more and more desktop users
are being trained that updates happen on a schedule they didn't choose
and are hard to avoid. This is how most mobile operating systems
function. Building on a lot of ideas already mentioned and adding a
few more, could we do something 'radical' and try to do rolling
releases 'right?' Warning, the below kind of destroys the release
concept or pushes us to actually do more "releases" but with less
software tied to the release.

Can we define a core of software using the Silverblue model that
supports booting the hardware. This lets us define LTS as a set of
hardware that we will keep running. This should solve most of the
goals around extending our lifecycle. We can explicitly announce new
hardware support and support that we are dropping as we push out new
OSTrees. We'd have one tree we support. I'd look to our kernel
friends to set the cadence on this. This would become the base for QE
of everything else.

The premise would be that declining an update should be a temporary
and deliberate decision with the goal being to, ideally quickly, get
to a point where the update can be accepted. A lot of us do this
today already when we delay updates because of travel, conferences, or
major projects we have to finish without risk. To be clear, updates
are still opt-in, but there is little to no promise of support if you
opt-out. I'd define the goal here as "everyone is running the latest
core."

Everything else (simplified statement) becomes an 'app' that can be
updated. This includes desktop environments. We make all upstream
supported releases available. This means that if, for example,
LibreOffice drops a release for maintenance it also drops out of
Fedora. This also means that we don't just add
modularity/flatpaks/contains, we need to embrace them. The core is
necessarily small. There may not be a central libfoo that a dozen
applications can depend on. They may all have to know they need
libfoo and get rebuilt and "updated" when there is a security fix in
libfoo.

This also means that refusing core or app updates may mean that your
apps/system eventually stop working. I think this is reasonable to
push onto users because upstreams are, by and large, also interested
in great user experiences. They aren't going to ordinarily make big
changes that destroy the user experience from release to release.
They want to keep their users as much as we do. As long as we echo
their updates, and provide warning on what changes to expect, we can
give people the information they need to make decisions about updates.

I think the same thing can be true for the server. I understand that
this is not necessarily the best server experience for production
environments, however, if we are going to be a place where we innovate
in the operating system, we need people running and testing that
innovation, not waiting on others to do it.

I've written all of this without my "Red Hat" on thinking solely about
our community and how I see it (for certain definitions of 'see' and
only on some days). I have no idea how RH would feel about a Fedora
that looked like this and I look to my friends who work directly on
product to comment. It could create a situation where the only
non-upstream supported app versions are those that RH maintains in
Fedora. Maybe they start maintaining those in CentOS (see below) - I
don't know.

I also think this opens up an even greater opportunity for partnership
with our friends in CentOS. How do we work together to make it even
easier for users to consume both distributions to meet their various
use cases? How can we cooperate with their SIGs to push stabilized
innovation into CentOS faster for longer term consumption? Not
everything in CentOS comes from RHEL, let's take advantage of that.

This has gotten long, so I'll stop here (and add a few PSs :D).

regards,

bex

PS: I realize that I am mostly restating the "half-rolling" argument,
describing mobile phone updates, and repeating many of the comments
that have been made about modularity/flatpaks/containers. But I
haven't seen them stated in this thread as a path forward for Fedora.

PPS: After writing all of this, and reflecting on the fact that I am
sitting in a conference populated mostly by employed developers
running Windows (and some Mac and Linux), I don't think this change
(or others mentioned in this thread so far) increases our desktop
adoption significantly. I don't think we are losing users to other
non-Linux platforms over update cadence. I'm also not convinced that
the majority of Linux users chose their distro primarily over this
concern either.

I'd be interested to hear these conversations restated in terms of
increasing adoption beyond just getting on to the shipping list at
Hardware vendor X. If the vendor isn't going to push Linux/Fedora,
then what are we going to do to become a chosen option, not just a
viable one?
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/ar

[Gerald Henriksen]

Post by Brian (bex) Exelbierd
I understand this argument, but I think more and more desktop users
are being trained that updates happen on a schedule they didn't choose
and are hard to avoid. This is how most mobile operating systems
function.

iOS prompts you for the yearly updates, and it can be avoided if you
really want.

macOS requires you to specifically choose the yearly update, though
they may have changed with Mojave.

Not sure about Android, but the fact that Google has had to twist
things into a knot to try and get updates out to users indicates that
upgrades to Android aren't being pushed out for the most part.

Windows is the only one forcing upgrades, and it is perhaps one of the
reasons that hardware vendors are showing more interest in Linux as
people are now more willing to consider anything other than Windows.

Really, the only place where forced upgrades are happening, are
accepted, and seem to actually work are on the application side and
that is because, demonstrated by the web browsers, frequent updates
can be done unobtrusively and reliably.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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.or

[Jiri Eischmann]

Post by Gerald Henriksen

Post by Brian (bex) Exelbierd
I understand this argument, but I think more and more desktop users
are being trained that updates happen on a schedule they didn't choose
and are hard to avoid. This is how most mobile operating systems
function.

iOS prompts you for the yearly updates, and it can be avoided if you
really want.
macOS requires you to specifically choose the yearly update, though
they may have changed with Mojave.
Not sure about Android, but the fact that Google has had to twist
things into a knot to try and get updates out to users indicates that
upgrades to Android aren't being pushed out for the most part.
Windows is the only one forcing upgrades, and it is perhaps one of the
reasons that hardware vendors are showing more interest in Linux as
people are now more willing to consider anything other than Windows.
Really, the only place where forced upgrades are happening, are
accepted, and seem to actually work are on the application side and
that is because, demonstrated by the web browsers, frequent updates
can be done unobtrusively and reliably.

And with the named examples are you gonna get any support and updates
if you decide to hold off an upgrade to a newer OS? I doubt.
I can certainly hold off upgrade to Android 9 on my phone, but that
doesn't mean I'm gonna get any further updates for Android 8 from the
phone vendor.
There is a huuuge difference between "not forcing upgrades" and
"providing supported and secure way to stay on the current release".

Jiri
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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

[m***@gnome.org]

Post by John Florian
I still don't understand what makes updating these for a *new*
release significantly easier than an *existing* one.&nbsp; So let's
just say GNOME (or whatever) comes out next month with a new major
release we want to showcase.&nbsp; Why is it necessary to have a
Fedora 30 to be able to realize this update.&nbsp; What is so
difficult about providing this for Fedora 29.&nbsp; I'm trying to
understand why these upstream updates can't be decoupled from the
Fedora release schedule.

It's all a matter of QA. The freeze, the blocker bug process, and the
quantity of users who test the stuff for us. We'd need major changes to
our updates process to account for this in a mid-release update. The
blocker bugs process would be needed, for a single bodhi update. At
least a month or two of testing (during which new versions of the
update will be released, so the update will have to go through some
iterations). And lots and lots of testers: currently we get those for
free because tons of people help us test beta releases of Fedora, I
think far more than run updates-testing.

This is all doable and solvable. Not a blocker. But if we don't take it
seriously and make some big changes in how we release updates, it won't
go well. Not well at all. So I'd recommend against it, unless there is
some major benefit available from doing so.

Michael

[John Florian]

Post by m***@gnome.org

Post by John Florian
I still don't understand what makes updating these for a *new*
release significantly easier than an *existing* one.&nbsp; So let's
just say GNOME (or whatever) comes out next month with a new major
release we want to showcase.&nbsp; Why is it necessary to have a
Fedora 30 to be able to realize this update.&nbsp; What is so
difficult about providing this for Fedora 29.&nbsp; I'm trying to
understand why these upstream updates can't be decoupled from the
Fedora release schedule.

It's all a matter of QA. The freeze, the blocker bug process, and the
quantity of users who test the stuff for us. We'd need major changes
to our updates process to account for this in a mid-release update.
The blocker bugs process would be needed, for a single bodhi update.
At leas t a month or two of testing (during which new versions of the
update will be released, so the update will have to go through some
iterations). And lots and lots of testers: currently we get those for
free because tons of people help us test beta releases of Fedora, I
think far more than run updates-testing.

I think if we did this right, however it looks, multiple testing repos,
rings, modularity, whatever... we might easily attract more testers than
we have now.  I think this whole problem can usually be distilled down
to, "I want LTS for everything because I hate breakage and I hate tech
treadmills because I've already got too much to do.  Except for Foo, the
version every other distro has is too old and I'm willing to get dirty
if necessary because Foo is what matters to me."

Post by m***@gnome.org
This is all doable and solvable. Not a blocker. But if we don't take
it seriously and make some big changes in how we release updates, it
won't go well. Not well at all. So I'd recommend against it, unless
there is some major benefit available from doing so.

I totally agree, but we are talking about radical changes here and I
think we should keep all options on the table.  If some particular path
forward is overwhelmingly desirable, that is the time to decide if the
push is worth it, not earlier IMHO.  If the proposal, whatever it be, is
great and everyone  agrees its great, the seriousness will be
automatic.  Fedora has a long history of catering to some niche ideals
that parts of our community are dead against.  It's awesome that Fedora
is so flexible, but if we're going to fiddle with the release model,
lets find something we *all* get behind and be happier with for the next
15 years, however radical it might look like right now.

[Japheth Cleaver]

Post by John Florian
I totally agree, but we are talking about radical changes here and I
think we should keep all options on the table.  If some particular
path forward is overwhelmingly desirable, that is the time to decide
if the push is worth it, not earlier IMHO.  If the proposal, whatever
it be, is great and everyone  agrees its great, the seriousness will
be automatic.  Fedora has a long history of catering to some niche
ideals that parts of our community are dead against.  It's awesome
that Fedora is so flexible, but if we're going to fiddle with the
release model, lets find something we *all* get behind and be happier
with for the next 15 years, however radical it might look like right now.

This becomes even more important when one takes into account Fedora's
position as the defacto head of the overall Red Hat -based distro
community, notwithstanding the Penrose Triangle presentiation...
EL-rebuild users (CentOS and SL) being on the far side of a
mostly-opaque hardening process are doubly removed from meaningful
input, and if a Fedora LTS of any type (rings, alternating intervals,
etc) is to address any of those needs, all RH-ecosystem users probably
have input worth soliciting.

I would submit that "Fedora" deciding an LTS policy might beg the
question. Maybe the answer is there being a stable/LTS upstream that
"Fedora" can itself (as one among peers) derive and override from,
Debian->Ubuntu style.

-jc

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraprojec

[Kevin Kofler]

Post by Michal Schorm
We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.
That allow us to manage changes like GCC, OpenSSL and so on quickly.
Struggling with upstream who don't adapt, can't adapt or don't want to
adapt at the same speed. (And OpenSSL patch isn't something you'd want
to write for serveral pojects you maintain ...)
That is what make us different distro with its own user base. Want the
very same but LTS system? try CentOS. Or RHEL.

+1. LTS Fedora is what CentOS is for. Why should we not just point users who
want LTS to CentOS and EPEL?

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/arch

[Carmen Bianca Bakker]

Post by Kevin Kofler

Post by Michal Schorm
That is what make us different distro with its own user base. Want the
very same but LTS system? try CentOS. Or RHEL.

+1. LTS Fedora is what CentOS is for. Why should we not just point users who
want LTS to CentOS and EPEL?

Crazy idea: Would it be possible to integrate CentOS into the Fedora
fold? I am not intimately familiar with the relation between CentOS and
Fedora, but I can see two radical(!) changes that would address this
topic:

- Completely absorb CentOS into Fedora. Every nth Fedora release
becomes the equivalent of a CentOS release, and will be supported for
a long time.

- Keep everything approximately the same, but rename CentOS to "Fedora
LTS".

I agree otherwise, though. Creating Fedora LTS seems like an effort in
futility when CentOS exists as a close enough approximation.

Best regards,
Carmen

[Przemek Klosowski]

Post by Kevin Kofler

Post by Michal Schorm
That is what make us different distro with its own user base. Want the
very same but LTS system? try CentOS. Or RHEL.

+1. LTS Fedora is what CentOS is for. Why should we not just point users who
want LTS to CentOS and EPEL?

Crazy idea: Would it be possible to integrate CentOS into the Fedora fold?

It's not a crazy idea at all, but the details are tricky. Since CentOS
is essentially a RHEL derivative, this would require RedHat
collaboration. In principle, Fedora is an R&D precursor for RHEL, but I
have not seen an official statement on how RedHat bakes RHEL out of Fedora.

If you squint at https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux
, it seems that they fork Fedora every 4 or so years, and take about a
year of QA, while selectively (?) back-porting subsequent Fedora
developments. The result is RedHat-branded and released as RHEL; whereas
CentOS follows up while stripping RedHat branding (yes, there's a
certain amount of forth-and-back :)


I wonder if RedHat could be persuaded to modify their process to adopt a
Fedora release instead of forking it, and backport into that
release---let's call it "Fedora LTS a.k.a. CentOS Release Candidate"
(FLAC-RC :). It would require perhaps more effort on the part of RedHat
to avoid breakage in the middle of their development cycle, but that's
probably a good CI practice anyway.

Matthew, do you think that is something that RedHat might be interested in?
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraprojec

[Brendan Conoboy]

Post by Przemek Klosowski

Post by Kevin Kofler

Post by Michal Schorm
That is what make us different distro with its own user base. Want the
very same but LTS system? try CentOS. Or RHEL.

+1. LTS Fedora is what CentOS is for. Why should we not just point users who
want LTS to CentOS and EPEL?

Crazy idea: Would it be possible to integrate CentOS into the Fedora fold?

It's not a crazy idea at all, but the details are tricky. Since CentOS
is essentially a RHEL derivative, this would require RedHat
collaboration. In principle, Fedora is an R&D precursor for RHEL, but
I have not seen an official statement on how RedHat bakes RHEL out of
Fedora.

Hey, Josh and I gave a talk about that at Flock. Hopefully we'll be
doing another at Devconf.

Post by Przemek Klosowski
If you squint at
https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux , it seems that
they fork Fedora every 4 or so years, and take about a year of QA,
while selectively (?) back-porting subsequent Fedora developments. The
result is RedHat-branded and released as RHEL; whereas CentOS follows
up while stripping RedHat branding (yes, there's a certain amount of
forth-and-back :)
I wonder if RedHat could be persuaded to modify their process to adopt
a Fedora release instead of forking it, and backport into that
release---let's call it "Fedora LTS a.k.a. CentOS Release Candidate"
(FLAC-RC :). It would require perhaps more effort on the part of
RedHat to avoid breakage in the middle of their development cycle, but
that's probably a good CI practice anyway.
Matthew, do you think that is something that RedHat might be
interested in?

The question ever on my mind is how do we balance the independence of
each distribution and its members while creating something we can
share that is net-positive for all. It will be complex, but there is
definitely room for more 3-way collaboration than is happening today.

--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject

[Florian Weimer]

Post by Przemek Klosowski
I wonder if RedHat could be persuaded to modify their process to adopt
a Fedora release instead of forking it, and backport into that
release---let's call it "Fedora LTS a.k.a. CentOS Release Candidate"
(FLAC-RC :). It would require perhaps more effort on the part of
RedHat to avoid breakage in the middle of their development cycle, but
that's probably a good CI practice anyway.

I'm not sure if the substantial changes in minor releases of Red Hat
Enterprise Linux would be acceptable to device vendors. Red Hat
Enterprise Linux is a commercially supported distribution, but includes
substantially more changes than typical LTS releases.

Thanks,
Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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@

[Leigh Scott]

Post by Matthew Miller
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?

I'm already overworked supporting old releases for the current 13 months, most of my time is spent on fedora next.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorapr

[Matthew Miller]

Post by Leigh Scott

Post by Matthew Miller
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?

I'm already overworked supporting old releases for the current 13 months,
most of my time is spent on fedora next.

I think any workable answer is going to need some sort of Rings approach
that allows different cadence for deliverables on top. Cinnamon, for
example, could be in Ring 2 and deliver a faster-moving experience.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fed

[Adam Samalik]

Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime versions such as Node.js? is it about
things like glibc? or kernel? Or does it need to be the whole distro as we
have it today?

In case we don't find a uniform solution that would fit all those cases (==
for the whole release as we know it today), focusing on those specific
levels (modules? rings?! ;) ) might help with different approaches could
help us at least a little bit. Well, considering there are some.

Post by Matthew Miller
Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk about how we might address
some of the users and use cases we're missing out on.
When I talk to people about this, I often get "hey, you should do LTS
or go to rolling releases.” As I've said before, on the surface that's
a weird thing to say, since the actual user impact of those two
different things is mostly _opposite_. So, digging in, it often really
means "I don't want the pain and fear of big OS upgrades".
We've addressed that in several ways: first, making upgrades better.
(Thanks everyone who has worked on that.) A Fedora release-to-release
update is normally not much more trouble than you might get some random
Tuesday with a rolling release. Second, we have some things like Fedora
Atomic Host and upcoming Fedora CoreOS and IoT which both implement a
rolling stream on top of the Fedora release base. And finally, there's
the coming-someday plans for gating Rawhide, making that a better
proposition for people who really want to live on the edge.
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.
So, what would this look like? I have some ideas, but, really, there
are many possibilities. That's what this thread is for. Let's figure it
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?
--
Matthew Miller
Fedora Project Leader
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

[Matthew Miller]

Post by Adam Samalik
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime versions such as Node.js? is it about
things like glibc? or kernel? Or does it need to be the whole distro as we
have it today?
In case we don't find a uniform solution that would fit all those cases (==
for the whole release as we know it today), focusing on those specific
levels (modules? rings?! ;) ) might help with different approaches could
help us at least a little bit. Well, considering there are some.

I'm thinking mostly about a base platform. And even there, I think kernel
versions and such can change -- we don't need a RHEL-style kernel ABI
promise. We just need changes there to not break 1) the hardware it runs on
and 2) the stuff on top.


--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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.

[Brendan Conoboy]

Post by Matthew Miller

Post by Adam Samalik
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime versions such as Node.js? is it about
things like glibc? or kernel? Or does it need to be the whole distro as we
have it today?
In case we don't find a uniform solution that would fit all those cases (==
for the whole release as we know it today), focusing on those specific
levels (modules? rings?! ;) ) might help with different approaches could
help us at least a little bit. Well, considering there are some.

I'm thinking mostly about a base platform. And even there, I think kernel
versions and such can change -- we don't need a RHEL-style kernel ABI
promise. We just need changes there to not break 1) the hardware it runs on
and 2) the stuff on top.

From my standpoint the thing to run slow to keep userspace ABI
compatible are the basic userspace enablers: system compilers, libc,
and other shared libraries that are commonly required by most of the
compiled packages. Similar for basic OS pieces: init system, dbus,
etc. Move the kernel faster, move the applications faster, but keep
that middle slower and stable. Having that platform live on the
gcc/libc 1 year cycle makes way more sense than the 6 month cycle we
have today.

--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/arch

[Laura Abbott]

Post by Matthew Miller

Post by Adam Samalik
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime versions such as Node.js? is it about
things like glibc? or kernel? Or does it need to be the whole distro as we
have it today?
In case we don't find a uniform solution that would fit all those cases (==
for the whole release as we know it today), focusing on those specific
levels (modules? rings?! ;) ) might help with different approaches could
help us at least a little bit. Well, considering there are some.

I'm thinking mostly about a base platform. And even there, I think kernel
versions and such can change -- we don't need a RHEL-style kernel ABI
promise. We just need changes there to not break 1) the hardware it runs on
and 2) the stuff on top.

So it's business as usual for the kernel then :)

More seriously, I do think we need to define what LTS actually means.
Especially for the kernel, there's already LTS defined upstream but that
may not align with what Fedora wants to do elsewhere. We may not want
a super strong RHEL ABI but actual LTS users may not want to deal with
other aspects of a kernel upgrade.

Laura
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/li

[drago01]

Post by Laura Abbott

Post by Matthew Miller

Post by Adam Samalik
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime versions such as Node.js? is it about
things like glibc? or kernel? Or does it need to be the whole distro as we
have it today?
In case we don't find a uniform solution that would fit all those cases (==
for the whole release as we know it today), focusing on those specific
levels (modules? rings?! ;) ) might help with different approaches could
help us at least a little bit. Well, considering there are some.

I'm thinking mostly about a base platform. And even there, I think kernel
versions and such can change -- we don't need a RHEL-style kernel ABI
promise. We just need changes there to not break 1) the hardware it runs on
and 2) the stuff on top.

So it's business as usual for the kernel then :)
More seriously, I do think we need to define what LTS actually means.
Especially for the kernel, there's already LTS defined upstream but that
may not align with what Fedora wants to do elsewhere. We may not want
a super strong RHEL ABI but actual LTS users may not want to deal with
other aspects of a kernel upgrade.

The kernel is actually transparent to most users. Userspace ABI is
guaranteed by upstream. So as long as kernel upgrades do not break users
won't see much of a difference.

The only two exceptions are:

1) Out of tree driver users
2) People buying new hardware

For 1) kernel upgrades might be a problem if there driver is not updated
fast enough

For 2) not having the upgrades is a problem because they would have to wait
months before they can use their new hardware.

So ignoring case 1) it would be indeed "business as usual"

(Assuming upgrades do not break the system but that's what testing is for).

[Brendan Conoboy]

Post by Laura Abbott

Post by Matthew Miller

Post by Adam Samalik
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime versions such as Node.js? is it about
things like glibc? or kernel? Or does it need to be the whole distro as we
have it today?
In case we don't find a uniform solution that would fit all those cases (==
for the whole release as we know it today), focusing on those specific
levels (modules? rings?! ;) ) might help with different approaches could
help us at least a little bit. Well, considering there are some.

I'm thinking mostly about a base platform. And even there, I think kernel
versions and such can change -- we don't need a RHEL-style kernel ABI
promise. We just need changes there to not break 1) the hardware it runs on
and 2) the stuff on top.

So it's business as usual for the kernel then :)
More seriously, I do think we need to define what LTS actually means.
Especially for the kernel, there's already LTS defined upstream but that
may not align with what Fedora wants to do elsewhere. We may not want
a super strong RHEL ABI but actual LTS users may not want to deal with
other aspects of a kernel upgrade.

Does Fedora remaining on the same kernel for a longer period of time
open up useful opportunities? EG, if the same kernel were the default
for a longer period of time would that help make it suitable for
factory installs? I really enjoy that the same Fedora release goes
through many kernels in its lifetime, but being able to buy an XPS
with Fedora would easily equal that delight.

--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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

[Florian Weimer]

Post by Brendan Conoboy
Does Fedora remaining on the same kernel for a longer period of time
open up useful opportunities? EG, if the same kernel were the default
for a longer period of time would that help make it suitable for
factory installs?

It would certainly help with factory installs which use out-of-tree
kernel modules.

On the other hand, I expect most vendors want to ship their own kernels
anyway, so maybe the issue is not important after all.

Thanks,
Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/archiv

[Josh Boyer]

Post by Laura Abbott

Post by Matthew Miller

Post by Adam Samalik
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime versions such as Node.js? is it about
things like glibc? or kernel? Or does it need to be the whole distro as we
have it today?
In case we don't find a uniform solution that would fit all those cases (==
for the whole release as we know it today), focusing on those specific
levels (modules? rings?! ;) ) might help with different approaches could
help us at least a little bit. Well, considering there are some.

I'm thinking mostly about a base platform. And even there, I think kernel
versions and such can change -- we don't need a RHEL-style kernel ABI
promise. We just need changes there to not break 1) the hardware it runs on
and 2) the stuff on top.

So it's business as usual for the kernel then :)
More seriously, I do think we need to define what LTS actually means.
Especially for the kernel, there's already LTS defined upstream but that
may not align with what Fedora wants to do elsewhere. We may not want
a super strong RHEL ABI but actual LTS users may not want to deal with
other aspects of a kernel upgrade.

Let's walk through this with some concrete examples. Assume for the
moment the primary usecase is getting Fedora as a default option on
laptop hardware from a variety of vendors, with a lifecycle of 36
months. What does that entail from a kernel perspective? I can see a
few things to balance.

a) You need a kernel that supports all the hardware on initial release.
b) You need a kernel that continues to support all the hardware if it
is rebased.
c) You need a kernel that can support the hardware found in the next
model after year 1
d) You need a kernel that can support the hardware found in the next
model after year 2
e) (If we're ambitious), you need a kernel that can support the
hardware for multiple vendor models across a 3 year timeframe.
f) Most importantly, you need a kernel that provides a consistent
interface to userspace for the full 36 months and does not regress
support for any hardware

At first glance, that looks like Fedora's existing kernel model could
work find. Rebase, pick up support for new hardware, done. However,
we know there are regressions in hardware support, and we also know
that some laptop models are going to have hardware that doesn't have
support in a released kernel version. So either you're looking at
backporting to some existing kernel version in some fashion, or doing
carefully tested rebases across laptop models, or a mix thereof.

That catch, as I see it, with using an upstream LTS kernel is that
it's great for stability and bugfixes. It's not great at meeting the
"support new hardware" part. Which means backports. The longer that
kernel is used, the further it drifts away from upstream, the harder
the backports become. I think doing this for 36months is totally
feasible, but we'd need to make sure we really look at it to
understand what it would take.

josh
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/dev

[Miroslav Suchý]

Post by Matthew Miller
I'd love to change these things. To do that, we need
something that lasts for 36-48 months.

So that means we will be supporting something like Fedora 23 nowadays. That is Firefox 41, mock 1.2, dnf 1.1.3, ruby
2.2. systemd 222, kernel 4.2.3, qemu 2.4 ...

Will this be useful for users? Or we will be hit by requests to rebase to a newer version? To backport some bugfix or
feature?

I can imagine having LTS Fedora version which will be released every three years, but *only if* we state that only
security issues will be fixed there - and even that will be hard packages like Firefox. And we strongly *enforce* no
rebases in this version.

Miroslav
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/lis

[Daniel P. Berrangé]

Post by Miroslav Suchý

Post by Matthew Miller
I'd love to change these things. To do that, we need
something that lasts for 36-48 months.

So that means we will be supporting something like Fedora 23 nowadays. That is Firefox 41, mock 1.2, dnf 1.1.3, ruby
2.2. systemd 222, kernel 4.2.3, qemu 2.4 ...
Will this be useful for users? Or we will be hit by requests to rebase to a newer version? To backport some bugfix or
feature?
I can imagine having LTS Fedora version which will be released every three years, but *only if* we state that only
security issues will be fixed there - and even that will be hard packages like Firefox. And we strongly *enforce* no
rebases in this version.

Enforcing "no rebases" would actually make a long life Fedora *worse* than
RHEL in places. For example, RHEL rebases libvirt and qemu[1] is almost every
minor update.

Regards,
Daniel

[1] Might no be obvious to some as there's actually 2 distinct QEMU RPMs
shipped, one never rebases & one always rebases.
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorapro

[m***@gnome.org]

On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller

Post by Matthew Miller
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.

Is 36 months an absolute minimum for getting onto consumer laptops?

Don't underestimate the difficulty of adding an extra year. 48 months
is a *lot* harder than 36. 36 is a lot harder than 24 or 27 (2 years
plus 3 month upgrade window).

Michael

[Matthew Miller]

Post by m***@gnome.org
Is 36 months an absolute minimum for getting onto consumer laptops?

Based on the conversations I've had, yes. We might be able to get some niche
acceptance with 27 months.



--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/arc

[Stephen John Smoogen]

But there are some good cases for a longer lifecycle. For one thing, this has been a really big blocker for getting Fedora shipped on hardware. Second, there are people who really could be happily running Fedora but since we don't check the tickbox, they don't even look at us seriously. I'd love to change these things. To do that, we need something that lasts for 36-48 months.
Is 36 months an absolute minimum for getting onto consumer laptops?
Don't underestimate the difficulty of adding an extra year. 48 months is a *lot* harder than 36. 36 is a lot harder than 24 or 27 (2 years plus 3 month upgrade window).

From what I have talked with in the past.. 3 years is their bare
minimum and 7 is their what we really want. It usually takes the
vendor about 3-6 months of work to make sure the OS works on their
hardware without major problems and then they want people to buy
support contracts for 3-5 years where the number of problems needed in
year 3-5 are none. [This means that they want to have Fedora N for 3-6
months before their laptops ship with it. So you ship them a frozen
preload before you release to public. They also want any shipped to
'last' for the warranty cycle because trying to deal with update
questions when N eol's in the middle costs them a lot.]

This matches the majority of laptop buyers whether they are developers
or home users. They cycle a laptop 4 to 5 years with 7-8 looking to be
the new average. They also don't update their OS unless it does it
auto-magically for them. This is where the majority of profits for
laptop sales come from so the manufacturers aim to please this segment
most. There isn't a large margin on laptop sales anymore


--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@l

[Ben Rosser]

Post by Stephen John Smoogen
From what I have talked with in the past.. 3 years is their bare
minimum and 7 is their what we really want. It usually takes the
vendor about 3-6 months of work to make sure the OS works on their
hardware without major problems and then they want people to buy
support contracts for 3-5 years where the number of problems needed in
year 3-5 are none. [This means that they want to have Fedora N for 3-6
months before their laptops ship with it. So you ship them a frozen
preload before you release to public. They also want any shipped to
'last' for the warranty cycle because trying to deal with update
questions when N eol's in the middle costs them a lot.]

If 7 years is what manufacturers really want, then it sounds like
CentOS is much better positioned to be get shipped on laptops than
Fedora. Instead of working on a new "Fedora LTS" for this usage case,
would time be better spent improving EPEL and CentOS for the
desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora
LTS" anyway, to be honest.

Ben Rosser
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedora

[Bill Nottingham]

Post by Ben Rosser

Post by Stephen John Smoogen
From what I have talked with in the past.. 3 years is their bare
minimum and 7 is their what we really want. It usually takes the
vendor about 3-6 months of work to make sure the OS works on their
hardware without major problems and then they want people to buy
support contracts for 3-5 years where the number of problems needed in
year 3-5 are none. [This means that they want to have Fedora N for 3-6
months before their laptops ship with it. So you ship them a frozen
preload before you release to public. They also want any shipped to
'last' for the warranty cycle because trying to deal with update
questions when N eol's in the middle costs them a lot.]

If 7 years is what manufacturers really want, then it sounds like
CentOS is much better positioned to be get shipped on laptops than
Fedora. Instead of working on a new "Fedora LTS" for this usage case,
would time be better spent improving EPEL and CentOS for the
desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora
LTS" anyway, to be honest.

The point of a Fedora LTS for these manufacturers, if it were to exist,
is to give them a channel to partner with, work on support with, and
a software base they can get needed changes into.

AFAIK, CentOS isn't set up to accept changes (into the base repo) or
provide that level of support. And if they wanted to do it with Red Hat
at the RHEL level... presumably they would already be doing so.

Bill
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/l

[Josh Boyer]

Post by Bill Nottingham

Post by Ben Rosser

Post by Stephen John Smoogen
From what I have talked with in the past.. 3 years is their bare
minimum and 7 is their what we really want. It usually takes the
vendor about 3-6 months of work to make sure the OS works on their
hardware without major problems and then they want people to buy
support contracts for 3-5 years where the number of problems needed in
year 3-5 are none. [This means that they want to have Fedora N for 3-6
months before their laptops ship with it. So you ship them a frozen
preload before you release to public. They also want any shipped to
'last' for the warranty cycle because trying to deal with update
questions when N eol's in the middle costs them a lot.]

If 7 years is what manufacturers really want, then it sounds like
CentOS is much better positioned to be get shipped on laptops than
Fedora. Instead of working on a new "Fedora LTS" for this usage case,
would time be better spent improving EPEL and CentOS for the
desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora
LTS" anyway, to be honest.

The point of a Fedora LTS for these manufacturers, if it were to exist,
is to give them a channel to partner with, work on support with, and
a software base they can get needed changes into.

Agreed. Fedora is well positioned to do that. In fact, it's well
positioned for the manufacturers themselves to get their software
changes in as well. I think there is an opportunity here for both
sides that's worth looking at.

Post by Bill Nottingham
AFAIK, CentOS isn't set up to accept changes (into the base repo) or
provide that level of support. And if they wanted to do it with Red Hat
at the RHEL level... presumably they would already be doing so.

That would presume a lot more as well. Do both parties want to pursue
that market? Do both parties get benefits from it? Are the
development models and support terms structured in a way that
facilitates that? Even if we assume an answer of "yes" for all of
those things and RHEL is pursuing it, that doesn't mean Fedora cannot
or should not, right?

josh
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.

[Bill Nottingham]

Post by Josh Boyer

Post by Bill Nottingham

Post by Ben Rosser
If 7 years is what manufacturers really want, then it sounds like
CentOS is much better positioned to be get shipped on laptops than
Fedora. Instead of working on a new "Fedora LTS" for this usage case,
would time be better spent improving EPEL and CentOS for the
desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora
LTS" anyway, to be honest.

The point of a Fedora LTS for these manufacturers, if it were to exist,
is to give them a channel to partner with, work on support with, and
a software base they can get needed changes into.

Agreed. Fedora is well positioned to do that. In fact, it's well
positioned for the manufacturers themselves to get their software
changes in as well. I think there is an opportunity here for both
sides that's worth looking at.

Post by Bill Nottingham
AFAIK, CentOS isn't set up to accept changes (into the base repo) or
provide that level of support. And if they wanted to do it with Red Hat
at the RHEL level... presumably they would already be doing so.

That would presume a lot more as well. Do both parties want to pursue
that market? Do both parties get benefits from it? Are the
development models and support terms structured in a way that
facilitates that? Even if we assume an answer of "yes" for all of
those things and RHEL is pursuing it, that doesn't mean Fedora cannot
or should not, right?

No, it doesn't mean Fedora can't do that. My main point is that I don't
see any situations where those answers are all 'yes' for CentOS, so I don't
think trying to position CentOS for this makes sense.... it either makes
sense for RHEL, or for Fedora (or for both).

Bill
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.

[Stephen John Smoogen]

Post by Ben Rosser

Post by Stephen John Smoogen
From what I have talked with in the past.. 3 years is their bare
minimum and 7 is their what we really want. It usually takes the
vendor about 3-6 months of work to make sure the OS works on their
hardware without major problems and then they want people to buy
support contracts for 3-5 years where the number of problems needed in
year 3-5 are none. [This means that they want to have Fedora N for 3-6
months before their laptops ship with it. So you ship them a frozen
preload before you release to public. They also want any shipped to
'last' for the warranty cycle because trying to deal with update
questions when N eol's in the middle costs them a lot.]

If 7 years is what manufacturers really want, then it sounds like

Well they also want a Ferrari and all support to be done upstream for
free. 7 is usually their counter to 13 months. You start going down
there to find that what they really settle for will be 3-4 years as
most people don't extend warranties that long.

Post by Ben Rosser
CentOS is much better positioned to be get shipped on laptops than
Fedora. Instead of working on a new "Fedora LTS" for this usage case,
would time be better spent improving EPEL and CentOS for the
desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora
LTS" anyway, to be honest.
Ben Rosser
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/archi

[Ben Rosser]

Post by Stephen John Smoogen

Post by Ben Rosser

Post by Stephen John Smoogen
From what I have talked with in the past.. 3 years is their bare
minimum and 7 is their what we really want. It usually takes the
vendor about 3-6 months of work to make sure the OS works on their
hardware without major problems and then they want people to buy
support contracts for 3-5 years where the number of problems needed in
year 3-5 are none. [This means that they want to have Fedora N for 3-6
months before their laptops ship with it. So you ship them a frozen
preload before you release to public. They also want any shipped to
'last' for the warranty cycle because trying to deal with update
questions when N eol's in the middle costs them a lot.]

If 7 years is what manufacturers really want, then it sounds like

Well they also want a Ferrari and all support to be done upstream for
free. 7 is usually their counter to 13 months. You start going down
there to find that what they really settle for will be 3-4 years as
most people don't extend warranties that long.

Well, even so, 3-4 years would be a pretty long time.

My point about EPEL was that, Fedora currently does produce a
long-term-support type product (admittedly for another distro). It's
EPEL.

Except we don't really push it. EPEL is an opt-in thing, which means
lots of packages don't have EPEL branches-- possibly because the
maintainers didn't want to commit to maintaining a package in a
long-term-support type environment, or possibly because the
maintainers never thought or bothered to create an EPEL branch, or
possibly because there are too many dependencies that don't exist in
EPEL and tracking down those maintainers isn't worth the time and
effort. I know that I would package more things for EPEL if I could
reuse Fedora specs with a minimum of fuss and I didn't have to spend
time getting a bunch of dependent packages built.

It is not clear to me that Fedora having two long-term-support type
products would be a good idea, as I am not sure that we have the
resources to maintain *one* at the moment. That makes me think we'd
want to tie a hypothetical "Fedora LTS" directly to RHEL/CentOS/EPEL
somehow, and find a way to reuse the work for both efforts.

Ben Rosser
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@list

[Naheem Zaffar]

The major OS competitor has moved to a 6 month release cadence, so that
needs to be taken into account.

I suspect the easiest way to have a longer supported system is by NOT
having a longer supported system. For the case of desktop hardware vendors
something like a constantly updating silverblue might fit better.

It could be a continuously updating system "automatically" moving to the
next release shortly after the next fedora version is released. As it is
image based breakage should be harder to occur.

It will be no more or less faster updated than competitor operating systems
that manufacturers use.

Post by Ben Rosser

Post by Stephen John Smoogen

Post by Ben Rosser

Post by Stephen John Smoogen
From what I have talked with in the past.. 3 years is their bare
minimum and 7 is their what we really want. It usually takes the
vendor about 3-6 months of work to make sure the OS works on their
hardware without major problems and then they want people to buy
support contracts for 3-5 years where the number of problems needed

in

Post by Stephen John Smoogen

Post by Ben Rosser

Post by Stephen John Smoogen
year 3-5 are none. [This means that they want to have Fedora N for

3-6

Post by Stephen John Smoogen

Post by Ben Rosser

Post by Stephen John Smoogen
months before their laptops ship with it. So you ship them a frozen
preload before you release to public. They also want any shipped to
'last' for the warranty cycle because trying to deal with update
questions when N eol's in the middle costs them a lot.]

If 7 years is what manufacturers really want, then it sounds like

Well they also want a Ferrari and all support to be done upstream for
free. 7 is usually their counter to 13 months. You start going down
there to find that what they really settle for will be 3-4 years as
most people don't extend warranties that long.

Well, even so, 3-4 years would be a pretty long time.
My point about EPEL was that, Fedora currently does produce a
long-term-support type product (admittedly for another distro). It's
EPEL.
Except we don't really push it. EPEL is an opt-in thing, which means
lots of packages don't have EPEL branches-- possibly because the
maintainers didn't want to commit to maintaining a package in a
long-term-support type environment, or possibly because the
maintainers never thought or bothered to create an EPEL branch, or
possibly because there are too many dependencies that don't exist in
EPEL and tracking down those maintainers isn't worth the time and
effort. I know that I would package more things for EPEL if I could
reuse Fedora specs with a minimum of fuss and I didn't have to spend
time getting a bunch of dependent packages built.
It is not clear to me that Fedora having two long-term-support type
products would be a good idea, as I am not sure that we have the
resources to maintain *one* at the moment. That makes me think we'd
want to tie a hypothetical "Fedora LTS" directly to RHEL/CentOS/EPEL
somehow, and find a way to reuse the work for both efforts.
Ben Rosser
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

[Gerald Henriksen]

Post by Naheem Zaffar
The major OS competitor has moved to a 6 month release cadence, so that
needs to be taken into account.

And Microsoft is experiencing troubles, and a lot of push back that
they are so far ignoring. Not all of the troubles are necessarily
from the 6 month release cycle, but I could see them eventually
following Apple with a yearly release.

Really the one to emulate if you want to use anyone as a reference is
Apple - they do an update once a year, they don't force it, yet the
almost all users quite happily do the upgrade in a relatively short
time period.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorap

[Gerald Henriksen]

Post by Stephen John Smoogen
From what I have talked with in the past.. 3 years is their bare
minimum and 7 is their what we really want. It usually takes the
vendor about 3-6 months of work to make sure the OS works on their
hardware without major problems and then they want people to buy
support contracts for 3-5 years where the number of problems needed in
year 3-5 are none. [This means that they want to have Fedora N for 3-6
months before their laptops ship with it. So you ship them a frozen
preload before you release to public. They also want any shipped to
'last' for the warranty cycle because trying to deal with update
questions when N eol's in the middle costs them a lot.]

I think this is the key that needs to be thought out before figuring
out if / how Fedora can meet that need.

Does this mean they need / want a new Fedora LTS every year, 2 years,
3 years? If they want 3 to 5 years of support, and the hardware is
released 2 years in to a LTS release, does that extend it to a 7 year
LTS?

Is that really a viable Linux desktop market given how the desktops
currently develop?

Perhaps this is a discussion that needs to be expanded from just
Fedora to also include KDE and Gnome?

Post by Stephen John Smoogen
This matches the majority of laptop buyers whether they are developers
or home users. They cycle a laptop 4 to 5 years with 7-8 looking to be
the new average. They also don't update their OS unless it does it
auto-magically for them. This is where the majority of profits for
laptop sales come from so the manufacturers aim to please this segment
most. There isn't a large margin on laptop sales anymore

I suspect the big problem is that it requires a total rethink of what
a distribution is and how it is created.

Because if you look at Windows, which is what this idea is really
talking about, yes the users are quite happy to never upgrade the OS
but that is to a large extent based on the fact that 3 or 4 years
after purchase they can still go and buy/download the latest
application and it will install and run.

That concept doesn't work very well currently with the lock step march
of an entire distro (which is essentially the OS and applications) to
newer, incompatible versions every 6 months.

Really, to support what the hardware vendors really want (even if they
aren't clearly saying it) involves moving anything non-core-os away
from the current packaging system (so for Fedora RPMS) and to some
sort of container that will work regardless of what the underlying
system is providing.

You have to be able to at the very least keep updating Firefox (as a
prime example) for that 5 years without forcing the upgrade of half
the os in the process.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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@

[Owen Taylor]

Thanks for starting this discussion, Matthew!

A few notes:

* My personal long-term dream is that all Fedora users are running
Silverblue, we do great automated QA testing, and upgrading from one
Fedora to the next is a non-event, and opt-out rather than opt-in, and
long term support would not be needed. We aren't there yet. :-)
* If we have a long-term support branch, the stuff that's in the
default install / the stuff that would be in a Silverblue image -
should be rebased very sparingly. I think we'd have to define this set
- it's bigger than the current "critical path".
* As we move higher up the stack, it's more reasonable for
maintainers to take an approach of maintaining a single version across
active Fedora branches - and we have various mechanism to make that
easier: packages.cfg, module stream expansion, Flatpaks.
* The kernel is a big question mark - our kernel maintenance strategy
really *assumes* that we can aggressively rebase, but if the Fedora
project is working with a hardware vendor, the kernel is the component
that the hardware vendor is probably going to be squeamish about. Not
sure what the solution here is - sync to a LTS kernel? Presumably part
of Fedora working with hardware vendors would be figuring a good
testing strategy so that updates get testing on the actual hardware
before going out.
* If we are offering a long term branch as a strategy to work with
hardware vendors, what happens when users *choose* to upgrade to a
newer stable Fedora?

- Owen

Post by Matthew Miller
Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk about how we might address
some of the users and use cases we're missing out on.
When I talk to people about this, I often get "hey, you should do LTS
or go to rolling releases.” As I've said before, on the surface that's
a weird thing to say, since the actual user impact of those two
different things is mostly _opposite_. So, digging in, it often really
means "I don't want the pain and fear of big OS upgrades".
We've addressed that in several ways: first, making upgrades better.
(Thanks everyone who has worked on that.) A Fedora release-to-release
update is normally not much more trouble than you might get some random
Tuesday with a rolling release. Second, we have some things like Fedora
Atomic Host and upcoming Fedora CoreOS and IoT which both implement a
rolling stream on top of the Fedora release base. And finally, there's
the coming-someday plans for gating Rawhide, making that a better
proposition for people who really want to live on the edge.
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.
So, what would this look like? I have some ideas, but, really, there
are many possibilities. That's what this thread is for. Let's figure it
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?
--
Matthew Miller
Fedora Project Leader
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@li

[Pierre-Yves Chibon]

Post by Owen Taylor
Thanks for starting this discussion, Matthew!
* My personal long-term dream is that all Fedora users are running
Silverblue, we do great automated QA testing, and upgrading from one
Fedora to the next is a non-event, and opt-out rather than opt-in, and
long term support would not be needed. We aren't there yet. :-)
* If we have a long-term support branch, the stuff that's in the
default install / the stuff that would be in a Silverblue image -
should be rebased very sparingly. I think we'd have to define this set
- it's bigger than the current "critical path".
* As we move higher up the stack, it's more reasonable for
maintainers to take an approach of maintaining a single version across
active Fedora branches - and we have various mechanism to make that
easier: packages.cfg, module stream expansion, Flatpaks.

packages.cfg?
I'm not sure I know what this refers to, would you have any pointers?

Thanks,
Pierre
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/d

[Neal Gompa]

Post by Pierre-Yves Chibon

Post by Owen Taylor
Thanks for starting this discussion, Matthew!
* My personal long-term dream is that all Fedora users are running
Silverblue, we do great automated QA testing, and upgrading from one
Fedora to the next is a non-event, and opt-out rather than opt-in, and
long term support would not be needed. We aren't there yet. :-)
* If we have a long-term support branch, the stuff that's in the
default install / the stuff that would be in a Silverblue image -
should be rebased very sparingly. I think we'd have to define this set
- it's bigger than the current "critical path".
* As we move higher up the stack, it's more reasonable for
maintainers to take an approach of maintaining a single version across
active Fedora branches - and we have various mechanism to make that
easier: packages.cfg, module stream expansion, Flatpaks.

packages.cfg?
I'm not sure I know what this refers to, would you have any pointers?

It's a new unknown feature of rpkg (and thus fedpkg) to let you
configure `fedpkg build` to build packages for multiple koji targets
at once from a single branch. If you choose to have a single "master"
branch instead of a branch for every distro release, you can use that
file to specify what distribution releases you should build for by
default with `fedpkg build`.



--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedo

[Richard Shaw]

Post by Neal Gompa
It's a new unknown feature of rpkg (and thus fedpkg) to let you
configure `fedpkg build` to build packages for multiple koji targets
at once from a single branch. If you choose to have a single "master"
branch instead of a branch for every distro release, you can use that
file to specify what distribution releases you should build for by
default with `fedpkg build`.

+1000

I'm all for having a more LTS type release (whatever the mechanism ends up
being) but packaging needs to be made a lot easier as most of us have
$DAYJOBS and in my case has nothing to do with Linux/FOSS or the like.
Everything I do is either squeezed in while taking a mental break from said
$DAYJOB or in my home office instead of spending time with the wife and
kids.

I see arbitrary branching (orthogonal to modularity) as part of that
solution. But again, it needs to be easy and well documented.

Thanks,
Richard

[Ken Dreyer]

Post by Matthew Miller
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware.

This is an interesting topic to me because I recently toured the
System76 factory here in Denver. They are engineering their own
operating system (Pop!_OS) on top of Ubuntu, and I would love to see
Fedora become more viable as a base in these types of situations.

We have a lot of data stored in Bodhi. I've wondered about mining the
security update data in particular to discover:

A) How many security updates that we push that would have affected
older versions of Fedora, over time? In other words, based on the
Fedora 28 data, how many security updates does Fedora 27 lack 3 months
past its EOL? 6 months? 12 months? That would give a rough scope of
the security situation and level of effort.

B) Is it possible to "mock rebuild" those security updates' SRPMs for
the EOL Fedora releases? How much harder does it get over time? This
could be a semi-automated way to experiment with extending the
lifecycle of older Fedoras.

Obviously this is not perfect, but I imagine that solely focusing on
security updates could help extend the lifecycle from 13 months to
maybe 25 months.

- Ken
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/arch

[Zbigniew Jędrzejewski-Szmek]

Post by Ken Dreyer

Post by Matthew Miller
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware.

This is an interesting topic to me because I recently toured the
System76 factory here in Denver. They are engineering their own
operating system (Pop!_OS) on top of Ubuntu, and I would love to see
Fedora become more viable as a base in these types of situations.
We have a lot of data stored in Bodhi. I've wondered about mining the
A) How many security updates that we push that would have affected
older versions of Fedora, over time? In other words, based on the
Fedora 28 data, how many security updates does Fedora 27 lack 3 months
past its EOL? 6 months? 12 months? That would give a rough scope of
the security situation and level of effort.

The answer is "a lot". I don't think we have any hard numbers, but
see https://pagure.io/fesco/issue/1935. Generally, it seems we can't
process the CVEs we get now.

"This result was limited to 1000 bugs." → that's just for CVEs.

Post by Ken Dreyer
B) Is it possible to "mock rebuild" those security updates' SRPMs for
the EOL Fedora releases? How much harder does it get over time? This
could be a semi-automated way to experiment with extending the
lifecycle of older Fedoras.
Obviously this is not perfect, but I imagine that solely focusing on
security updates could help extend the lifecycle from 13 months to
maybe 25 months.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproj

[Matthew Miller]

Post by Zbigniew Jędrzejewski-Szmek
The answer is "a lot". I don't think we have any hard numbers, but
see https://pagure.io/fesco/issue/1935. Generally, it seems we can't
process the CVEs we get now.
"This result was limited to 1000 bugs." → that's just for CVEs.

What happens if we limit that to a smaller subset, though?


--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject.or

[Zbigniew Jędrzejewski-Szmek]

Post by Matthew Miller

Post by Zbigniew Jędrzejewski-Szmek
The answer is "a lot". I don't think we have any hard numbers, but
see https://pagure.io/fesco/issue/1935. Generally, it seems we can't
process the CVEs we get now.
"This result was limited to 1000 bugs." → that's just for CVEs.

What happens if we limit that to a smaller subset, though?

What do you mean?

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/archive

[Matthew Miller]

Post by Zbigniew Jędrzejewski-Szmek

Post by Matthew Miller

Post by Zbigniew Jędrzejewski-Szmek
The answer is "a lot". I don't think we have any hard numbers, but
see https://pagure.io/fesco/issue/1935. Generally, it seems we can't
process the CVEs we get now.
"This result was limited to 1000 bugs." → that's just for CVEs.

What happens if we limit that to a smaller subset, though?

What do you mean?

There are zillions of CVES across all of the packages in the entire Fedora
collection. How many are there against, say, the subset used for the IoT
spin (and potential future edition)?

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject.org

[Zbigniew Jędrzejewski-Szmek]

Post by Matthew Miller

Post by Zbigniew Jędrzejewski-Szmek

Post by Matthew Miller

Post by Zbigniew Jędrzejewski-Szmek
The answer is "a lot". I don't think we have any hard numbers, but
see https://pagure.io/fesco/issue/1935. Generally, it seems we can't
process the CVEs we get now.
"This result was limited to 1000 bugs." → that's just for CVEs.

What happens if we limit that to a smaller subset, though?

What do you mean?

There are zillions of CVES across all of the packages in the entire Fedora
collection. How many are there against, say, the subset used for the IoT
spin (and potential future edition)?

bluez, nginx, systemd, mysql, gdb, bzip2, openjpg, imagemagick,
shutter, exiv2, libexif, libkdcraw, glibc, php, busybox, tcpdump,
bintuils, that's from the top of the list.

I love Fedora, but the idea that you can take a 3 year old Fedora and
put it out on the web is just bonkers. We don't have the manpower and
the procedures to make Fedora suitable for this kind of use. We *could*
change what Fedora is, by making it stable and long-lived, but at least
I would then find a different distro to hack on.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/

[Matthew Miller]

Post by Zbigniew Jędrzejewski-Szmek
I love Fedora, but the idea that you can take a 3 year old Fedora and
put it out on the web is just bonkers. We don't have the manpower and
the procedures to make Fedora suitable for this kind of use.

Wellllllll, from my statistics, there's a lot of 3-year-old (and older!)
Fedora out on the web today. But that aside, let's say we wanted to do it
right *and* still keep the distro exciting and fun to hack on.

What person-power and procedures would we need to add?



--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedora

[Zbigniew Jędrzejewski-Szmek]

Post by Matthew Miller

Post by Zbigniew Jędrzejewski-Szmek
I love Fedora, but the idea that you can take a 3 year old Fedora and
put it out on the web is just bonkers. We don't have the manpower and
the procedures to make Fedora suitable for this kind of use.

Wellllllll, from my statistics, there's a lot of 3-year-old (and older!)
Fedora out on the web today. But that aside, let's say we wanted to do it
right *and* still keep the distro exciting and fun to hack on.
What person-power and procedures would we need to add?

This is like asking how to turn Fedora into RHEL or Debian stable w/ support.
I think we'd need to
a) specify a set of packages, the "core",
everything outside in the "universe" is not supported
b) find people to provide support for the lifetime of the edition
c) enforce the update policies to only do limited updates in old versions
d) find people to QA for those updates as they happen

I think it just requires a whole new set of people working on this. It's
not only that this is additional and different work. It's also that this
requires a *different mindset*. I think one of the reasons that Debian finds
it so hard to move, is because they *have* reached this mindset, and now
every new thing is suspicious and best-avoided. Long-term stability is
at odds with "First", and I think if we try to do that, we'll never do
it very well, but the things we are quite good at will suffer anyway.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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

[Florian Weimer]

Post by Matthew Miller

Post by Zbigniew Jędrzejewski-Szmek
I love Fedora, but the idea that you can take a 3 year old Fedora and
put it out on the web is just bonkers. We don't have the manpower and
the procedures to make Fedora suitable for this kind of use.

Wellllllll, from my statistics, there's a lot of 3-year-old (and older!)
Fedora out on the web today. But that aside, let's say we wanted to do it
right *and* still keep the distro exciting and fun to hack on.
What person-power and procedures would we need to add?

Make it cheap to maintain branches. I expect that one what to achieve
this would be to build directly out of Git, with synthesized release
numbers and changelogs. This way, you can apply a lot of fixes to
multiple branches without encountering mandatory conflicts.

There is no technical reason why the payload in an SRPMs cannot contain
the full exploded upstream source tree, with an RPM spec file in the
root.

Thanks,
Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fe

[Stephen John Smoogen]

Post by Florian Weimer

Post by Matthew Miller

Post by Zbigniew Jędrzejewski-Szmek
I love Fedora, but the idea that you can take a 3 year old Fedora and
put it out on the web is just bonkers. We don't have the manpower and
the procedures to make Fedora suitable for this kind of use.

Wellllllll, from my statistics, there's a lot of 3-year-old (and older!)
Fedora out on the web today. But that aside, let's say we wanted to do it
right *and* still keep the distro exciting and fun to hack on.
What person-power and procedures would we need to add?

Make it cheap to maintain branches. I expect that one what to achieve
this would be to build directly out of Git, with synthesized release
numbers and changelogs. This way, you can apply a lot of fixes to
multiple branches without encountering mandatory conflicts.
There is no technical reason why the payload in an SRPMs cannot contain
the full exploded upstream source tree, with an RPM spec file in the
root.

What do you mean that the fully exploded upstream source tree? Is it
the entire 'git' repository with all branches in it or just a tar ball
of a particular branch?

[The git repository can grow to hundreds of gigabytes which would make
every update a huge SRPM file for a small change.]

--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/

[Neal Gompa]

Post by Stephen John Smoogen

Post by Florian Weimer

Post by Matthew Miller

Post by Zbigniew Jędrzejewski-Szmek
I love Fedora, but the idea that you can take a 3 year old Fedora and
put it out on the web is just bonkers. We don't have the manpower and
the procedures to make Fedora suitable for this kind of use.

Wellllllll, from my statistics, there's a lot of 3-year-old (and older!)
Fedora out on the web today. But that aside, let's say we wanted to do it
right *and* still keep the distro exciting and fun to hack on.
What person-power and procedures would we need to add?

Make it cheap to maintain branches. I expect that one what to achieve
this would be to build directly out of Git, with synthesized release
numbers and changelogs. This way, you can apply a lot of fixes to
multiple branches without encountering mandatory conflicts.
There is no technical reason why the payload in an SRPMs cannot contain
the full exploded upstream source tree, with an RPM spec file in the
root.

What do you mean that the fully exploded upstream source tree? Is it
the entire 'git' repository with all branches in it or just a tar ball
of a particular branch?
[The git repository can grow to hundreds of gigabytes which would make
every update a huge SRPM file for a small change.]

He's proposing Debian-style source code forking into git repos and
having the build description merged into that source tree. It's
usually referred to as merged-source builds.

Basically, we no longer use pristine sources as inputs for package builds.



--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/d

[Matthew Miller]

Post by Neal Gompa
He's proposing Debian-style source code forking into git repos and
having the build description merged into that source tree. It's
usually referred to as merged-source builds.
Basically, we no longer use pristine sources as inputs for package builds.

Although, arguably, what constitutes a "pristine source" has changed.
Release tarballs are often an afterthought -- or something generated
automatically by GitHub -- while the tagged git tree is what the upstream
project themselves consideres to be the true authoritative source.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject.or

[Ken Dreyer]

Post by Florian Weimer
Make it cheap to maintain branches. I expect that one what to achieve
this would be to build directly out of Git, with synthesized release
numbers and changelogs. This way, you can apply a lot of fixes to
multiple branches without encountering mandatory conflicts.
There is no technical reason why the payload in an SRPMs cannot contain
the full exploded upstream source tree, with an RPM spec file in the
root.

One of the problems I've encountered with this approach is that the
upstream Git repo links to (a lot of) submodules. If you're lucky
those submodules point at Git repos and sha1s that don't disappear
over time. It doesn't really capture the entire "source" like I get
with an upstream release tarball.

- Ken
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/l

[Matthew Miller]

Post by Ken Dreyer
One of the problems I've encountered with this approach is that the
upstream Git repo links to (a lot of) submodules. If you're lucky
those submodules point at Git repos and sha1s that don't disappear
over time. It doesn't really capture the entire "source" like I get
with an upstream release tarball.

I think to do this we would need to have our own, controlled local git
mirror.


--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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@

[Colin Walters]

Post by Matthew Miller

Post by Ken Dreyer
One of the problems I've encountered with this approach is that the
upstream Git repo links to (a lot of) submodules. If you're lucky
those submodules point at Git repos and sha1s that don't disappear
over time. It doesn't really capture the entire "source" like I get
with an upstream release tarball.

I think to do this we would need to have our own, controlled local git
mirror.

This is step 2 in
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/li

[Ken Dreyer]

Post by Colin Walters

Post by Matthew Miller
I think to do this we would need to have our own, controlled local git
mirror.

This is step 2 in
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md

I am sorry to be such a noob, but I read the words on that page, they
sound exciting, but I am lost. What does "mirror git repositories like
rpmdistro-gitoverlay does" mean? I could use a really clear
step-by-step walkthrough of how I might do this for a traditional
package.

- Ken
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedorap

[Colin Walters]

Post by Ken Dreyer
I am sorry to be such a noob, but I read the words on that page, they
sound exciting, but I am lost. What does "mirror git repositories like
rpmdistro-gitoverlay does" mean? I could use a really clear
step-by-step walkthrough of how I might do this for a traditional
package.

The doc does assume that the reader has some familiarity with
the rpmdistro-gitoverlay project, yes. I'll look at tweaking that
doc to mention looking at the toplevel README.

rpmdistro-gitoverlay *replaces* koji, it isn't something you can use
on a "traditional package".

Anyways, it's pretty simple, rpmdistro-gitoverlay does a recursive
git mirror in to src/ - and recursive here includes submodules, for
exactly the reason you raised. A number of important real-world
modules use them (including ostree/rpm-ostree).
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/

[Ken Dreyer]

Post by Colin Walters
The doc does assume that the reader has some familiarity with
the rpmdistro-gitoverlay project, yes. I'll look at tweaking that
doc to mention looking at the toplevel README.

I looked at the top-level README but I gotta admit I was equally lost.
And it says it "is no longer under active development", so I'm not
sure what the status is.

Post by Colin Walters
rpmdistro-gitoverlay *replaces* koji, it isn't something you can use
on a "traditional package".

Thanks, this was one of the missing pieces for me :) It would help to
expand this out in that document.

Post by Colin Walters
Anyways, it's pretty simple, rpmdistro-gitoverlay does a recursive
git mirror in to src/ - and recursive here includes submodules, for
exactly the reason you raised. A number of important real-world
modules use them (including ostree/rpm-ostree).

I see, so it's dynamically re-writing the .gitmodules file(s) on each build?

We had something like this in Ceph,
https://github.com/ceph/autobuild-ceph/blob/master/use-mirror.sh
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproje

[Florian Weimer]

Post by Ken Dreyer

Post by Florian Weimer
Make it cheap to maintain branches. I expect that one what to achieve
this would be to build directly out of Git, with synthesized release
numbers and changelogs. This way, you can apply a lot of fixes to
multiple branches without encountering mandatory conflicts.
There is no technical reason why the payload in an SRPMs cannot contain
the full exploded upstream source tree, with an RPM spec file in the
root.

One of the problems I've encountered with this approach is that the
upstream Git repo links to (a lot of) submodules. If you're lucky
those submodules point at Git repos and sha1s that don't disappear
over time. It doesn't really capture the entire "source" like I get
with an upstream release tarball.

You wouldn't have to actually merge the upstream history. You can still
merge against tarball contents or other kinds of imports.

What is needed is some form of branch contents tracking, though. But we
struggle with this at least for Red Hat Enterprise Linux in the current
model, too, because each time we rebase from Fedora, we use some
downstream customizations—some unnecessary, some less so.

Thanks,
Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/archiv

[Sheogorath]

Post by Matthew Miller
So, what would this look like? I have some ideas, but, really, there
are many possibilities. That's what this thread is for. Let's figure it
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?

I know that 13 month for hardware vendors is quite short. Some of them
have processes for approving minor updates that take 6 month or longer.
We don't talk about a new kernel update here, we really talk about a
simple update of a client application in the IoT world.

So good so far, it makes sense that they are quite unhappy with Fedora
13 month release cycles. At the same time, one of the main reasons I use
fedora is because updates are so smooth in the recent releases. I think
that's something we can bring to IoT devices as well. With ostree and
the newer ways of upgrading systems it's definitely possible to upgrade
software quite fail safe.

I would go for one more release cycle that is supported (18-19 months)
instead of going for full LTS. Since LTS is really something I think
CentOS and RHEL should do. 10 years is LTS. 36 month is only half way,
and when we want IoT devices to become more secure in the long term, I
think we should work on making them safer and easier to update instead
of setting up an LTS which then causes ugly breaking during upgrades
which we see on Ubuntu and other places.

At least that's my experience and why I would like to avoid an LTS life
cycle. And 36 or 48 months are quite short for IoT (think about the
toaster you bought. How old is it?) but quite long in the world of software.

And for Vendors of notebooks and desktops, I think the upgrade process
is ready to work for end users. Especially on defaults.

When we look here to Windows, with Windows 10 they do exactly that.
Providing a Release that lasts 6 month (+ something for business) and
then is updated. We do this for 15 years now and quite smooth, so why
change? 13 months are completely fine for a desktop.

Finally people. We have resource, but not an infinite number of them. We
have so many projects we are working on and right now automatic various
of our existing projects already takes so much work time that adding
more release cycles would only make it harder. Especially with back
porting all the fixes to the then LTS. And besides that I guess most
people who want an LTS outside of the IoT world, would go for CentOS
anyway. So may let's see if we can bring CentOS and RHEL towards IoT
instead of bringing CentOS and RHEL to Fedora. I hope/guess the way for
the latter is way shorter.

[Bruno Postle]

Post by Matthew Miller
Hi everyone! Let's talk about something new and exciting.

Assuming a system that is automatically updating, but doesn't get upgraded to the next fedora release - a system like this needs to degrade progressively but securely: after thirteen months GUI applications are unsupported and are actively removed by dnf updates; after four years network servers are unsupported, shut down and removed; after seven years sshd is removed, default runlevel set to 1; after ten years runlevel is set to zero.

This is how you allow longer term support for server applications, without supporting old GUI software, and without leaving zombie machines (and virtual machines) laying around on the net causing trouble. This would be responsible lifecycle management.

--
Bruno
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/archive

[Jiri Eischmann]

Post by Matthew Miller
Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk about how we might
address
some of the users and use cases we're missing out on.
When I talk to people about this, I often get "hey, you should do LTS
or go to rolling releases.” As I've said before, on the surface that's
a weird thing to say, since the actual user impact of those two
different things is mostly _opposite_. So, digging in, it often really
means "I don't want the pain and fear of big OS upgrades".
We've addressed that in several ways: first, making upgrades better.
(Thanks everyone who has worked on that.) A Fedora release-to-release
update is normally not much more trouble than you might get some random
Tuesday with a rolling release. Second, we have some things like Fedora
Atomic Host and upcoming Fedora CoreOS and IoT which both implement a
rolling stream on top of the Fedora release base. And finally,
there's
the coming-someday plans for gating Rawhide, making that a better
proposition for people who really want to live on the edge.
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily
running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.
So, what would this look like? I have some ideas, but, really, there
are many possibilities. That's what this thread is for. Let's figure it
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?

We've done a really good job stabilizing Fedora, but based on
observations and conversations with users I think the model has been
getting to its limit in terms of userbase. There are simply too many
deplyoments which require a different kind of stability than the
current Fedora can offer (things may not break, but they still change
and change often). That's why I think LTS is an opportunity for us to
grow.
If we want to have an LTS I think we have to give up something. It'd be
really difficult to do it on the top of the 6-month releases. An idea
I've been entertaining recently is something like this:

- unstable rolling release (Rawhide)
- stable rolling release (basically gated Rawhide with stable versions
of components) - for the early adopters who want the latest and
greatest
- LTS
It would definitely need multiple groups with different treatment:
Ring 1 - kernel+base user space, stability is the highest priority, if
any rebases, then very well tested.
Ring 2 - e.g. desktop environments, rebases allowed, but well tested
and planned, perhaps aligned with some minor releases of Fedora LTS
(.1, .2,...).
Ring 3 - rolling release components, those can be based on the stable
rolling release Fedora and shipped via Flatpak/modules... maintainers
can then only support one version for all releases of Fedora, this can
be a viable mode for most desktop apps.

Jiri
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lis

[Greg Bailey]

Post by Matthew Miller
Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk about how we might address
some of the users and use cases we're missing out on.

I'm mostly a CentOS user with various 3rd party repositories like EPEL
and IUS configured for things like newer python, etc.  I'm an occasional
Fedora user (and packager for half a dozen or so packages).  I've
considered switching to a Fedora desktop but have yet to take the step
of reloading my primary workstation with Fedora (since I can't directly
upgrade from CentOS).

Post by Matthew Miller
So, what would this look like? I have some ideas, but, really, there
are many possibilities. That's what this thread is for. Let's figure it
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?

I saw the announcement for RHEL 8 beta and downloaded the ISO to see
what's on it.  It looks like it supports Application Streams, which I
assume is the same thing or related to Fedora modules?  The RHEL 8 beta
appears to have multiple versions of php, perl, nodejs, and other
packages.  I've not yet used Fedora modules nor RHEL 8 beta, but I bring
this up to see if that model meets the needs for Fedora users who are
looking for something along the lines of "Fedora LTS"?

-Greg
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject.

[Matthew Miller]

beta appears to have multiple versions of php, perl, nodejs, and
other packages.  I've not yet used Fedora modules nor RHEL 8 beta,
but I bring this up to see if that model meets the needs for Fedora
users who are looking for something along the lines of "Fedora LTS"?

It's definitely a tool we have in the box, at least.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fe