Sorry about the two lines of the letter that do not fit much into the concept:
So, I like the idea of one major and one minor release, if we want to stay conservative and do not want to go the rolling updates way. And, in case we want to stay super conservative and we do not want change anything, I think Debarshi's approach would work just fine. Thanks for understanding, Lukas On Wed, Nov 28, 2018 at 10:20 AM Lukas Ruzicka <lruzi...@redhat.com> wrote: > 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...@lostca.se> 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@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@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 > > lruzi...@redhat.com > TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted> > -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzi...@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
