On Tue, Nov 27, 2018 at 10:40 AM Owen Taylor <otaylor(a)redhat.com&gt; wrote: > > One of the key parts of making a decision to delay/skip F31 is > figuring out, ahead of the decision, what the expected experience is > for users and packagers. Does F30 have normal stability, or do we try > to keep users happy by moving things forward with ad-hoc updates and > cross-our-fingers and hope nothing breaks? > > I tend to think about this in terms of GNOME - would we rebase to > GNOME 3.34 in the middle of F30 or not? But there's a lot of other > pieces of software where similar considerations apply: container > tools, cockpit, NetworkManager, etc. > > And if we did do updates like that, would we consider respinning media > and making a "F30.1"? As came up in another part of the earlier thread, I think this is an opportunity for Modularity. For those things like GNOME that want to rev mid-release, if they shipped the 3.34 release as new stream, those that want to move to it will have that option, and those who fear change can remain on the 3.32 release, even if it's not getting support. This would have to be something communicated at release-time of course. _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)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@lists.fedoraproject.org

On Tue, Nov 27, 2018 at 10:40 AM Owen Taylor <otaylor(a)redhat.com&gt; wrote: > > One of the key parts of making a decision to delay/skip F31 is > figuring out, ahead of the decision, what the expected experience is > for users and packagers. Does F30 have normal stability, or do we try > to keep users happy by moving things forward with ad-hoc updates and > cross-our-fingers and hope nothing breaks? > > I tend to think about this in terms of GNOME - would we rebase to > GNOME 3.34 in the middle of F30 or not? But there's a lot of other > pieces of software where similar considerations apply: container > tools, cockpit, NetworkManager, etc. > > And if we did do updates like that, would we consider respinning media > and making a "F30.1"? As came up in another part of the earlier thread, I think this is an opportunity for Modularity. For those things like GNOME that want to rev mid-release, if they shipped the 3.34 release as new stream, those that want to move to it will have that option, and those who fear change can remain on the 3.32 release, even if it's not getting support. This would have to be something communicated at release-time of course.

On Tue, Nov 27, 2018 at 10:51 AM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote: > As came up in another part of the earlier thread, I think this is an > opportunity for Modularity. For those things like GNOME that want to > rev mid-release, if they shipped the 3.34 release as new stream, those > that want to move to it will have that option, and those who fear > change can remain on the 3.32 release, even if it's not getting > support. This would have to be something communicated at release-time > of course. If we want to offer optional GNOME-3.34, a module is probably a better alternative to using a copr - which is what we did last time. (https://copr.fedorainfracloud.org/coprs/rhughes/f20-gnome-3-12/) But we have to recognize that if we create such a module we are effectively creating a Fedora 30.1 - because libraries in that module will replace system libraries. From the point where we release such a module, any RPM-packaged applications that use GNOME libraries will have to be tested against *both* F30 and F30+gnome-3-34. It's also a minimally scalable approach - we wouldn't want to have a GNOME 3.34 module and a NetworkManager-1.16 module and support arbitrary combinations. And we'd have to figure out some strategy for not breaking F31 updates when you have the desktop:3.34 module enabled.

One of the key parts of making a decision to delay/skip F31 is figuring out, ahead of the decision, what the expected experience is for users and packagers. Does F30 have normal stability, or do we try to keep users happy by moving things forward with ad-hoc updates and cross-our-fingers and hope nothing breaks? I tend to think about this in terms of GNOME - would we rebase to GNOME 3.34 in the middle of F30 or not? But there's a lot of other pieces of software where similar considerations apply: container tools, cockpit, NetworkManager, etc. And if we did do updates like that, would we consider respinning media and making a "F30.1"?

Hello, I do not think that we should be taking the path towards Gnome being in one module. This is not, what "modular" means. In my understanding, modules should be smaller, rather independent units, that will help solve some user cases, but definitely not upgrading half of the system. Also, if we should provide updated ISOs, as one of the ideas was, why not do a normal release instead? It does not have to be packed with all new stuff, fixes and minor updates could be just fine ... and the new Gnome. I think there are several strategies, where we could go next, for example: - Release regularly to get the new Gnome, but do not push for so many new features in Fedora 31, if we need more time to fix things. - Adopt the Major / Minor approach and make the autumn release a minor one, so that Fedora 31 becomes a minor release. - Adopt the "rolling updates" strategy for Fedora and introduce a Fedora LTS that would be here for people who do not want rolling updates. - Just skip the release with all the consequences it will have ... no updates to new versions Let us not make Fedora messy by creating huge modules with dependencies in the whole system. It is too risky to go that way, because modularity is just at its beginning and has issues we must solve first. For example, what happens if you have a module stream installed and all the dependencies in a working system and you want to change from one stream to another? As far as I know, nobody guarantees at the moment, that the dependencies will not break. Can you image how putting Gnome into a module will affect the system when this is not solved? I'd rather see Fedora stay a bit older for a period of time than to see it breaking and leaving people angry. Take care, Lukas I quite like the idea of one major and one minor release in a year. I think that Debarshi's approach would work nicely On Wed, Nov 28, 2018 at 9:34 AM Debarshi Ray <rishi.is(a)lostca.se&gt; wrote: > On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote: > > One of the key parts of making a decision to delay/skip F31 is > > figuring out, ahead of the decision, what the expected experience is > > for users and packagers. Does F30 have normal stability, or do we try > > to keep users happy by moving things forward with ad-hoc updates and > > cross-our-fingers and hope nothing breaks? > > > > I tend to think about this in terms of GNOME - would we rebase to > > GNOME 3.34 in the middle of F30 or not? But there's a lot of other > > pieces of software where similar considerations apply: container > > tools, cockpit, NetworkManager, etc. > > > > And if we did do updates like that, would we consider respinning media > > and making a "F30.1"? > > Umm... can't we treat it the same as the Fedora 20/21 situation? > Skipping a GNOME release can be a bit painful for the upstream GNOME > community, which is overwhelmingly tilted towards Fedora, but it's not > the end of the world either. After all, I don't think the longer > Fedora 21 cycle had any negative long-term effect on that group at > all. :) > > The Desktop Team could more aggressively backport bug-fixes to GNOME > 3.34 upstream, and if needed backport selected features to Fedora 30 > downstream. We have done this during the usual six month Fedora > releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we > have done this for RHEL too, so there's some precedence in this area. > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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@lists.fedoraproject.org > -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzicka(a)redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

One of the key parts of making a decision to delay/skip F31 is figuring out, ahead of the decision, what the expected experience is for users and packagers. Does F30 have normal stability, or do we try to keep users happy by moving things forward with ad-hoc updates and cross-our-fingers and hope nothing breaks? I tend to think about this in terms of GNOME - would we rebase to GNOME 3.34 in the middle of F30 or not? But there's a lot of other pieces of software where similar considerations apply: container tools, cockpit, NetworkManager, etc.

On Thu, 29 Nov 2018 12:15:52 +0000, you wrote: >From an IoT perspective where we're looking at some features around >security that could be cross component dependent >(toolchain/kernel/userspace) to be unable to consume for possibly an >18 month window, yes we rebase kernels but we need to rebase other >components and build against those, in a stable release is a complete >and utter disaster. Is it specific to the F30/31 timeframe, or is it something that could be alleviated by instead delaying to a F31/32 delay? In other words, if the delay is necessary is there a better choice of time to do it that would help to minimize the disruption to the various Fedora communities?

This is basically the problem I have with the work we're doing in IoT. The basically will make me re-evaluate if IoT is now worth doing at all in Fedora or whether I am now better off focusing my efforts elsewhere.

On Sat, 1 Dec 2018 at 08:50, Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote: > > Folks, hi. > > Planning for a specific delay for a specific reason is one thing. But > the same design philosophy reasons that apply to Fedora 31 have > applied to almost every other Fedora releases, and changing to an > annual cycle is going to drive people *nuts* when updates for their > particular critical components get delayed up to 18 months because > they missed the *current* release and have to wait for the next major > release for the dependencies to be built up. This especially plays out > with tools that use many distinct small modules by different authors, > such as Python. Have you *looked* at what happens if python modules > are even slightly out of date, and the dependency chain that "pip > instlal" brings in? > I think the thinking is that you would make these modules and would just make them available during a release. You put a 12 month lifetime on each module set you are running and put out updated ones when you are ready to do so. The modules get retired over time and you are running your own 'release'. Of course this works better if packagers team up together and own the module versus trying to do it all themselves.. which is also assumed but may not have been realized by the packagers yet :).