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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Lukáš Růžička
FEDORA QE, RHCE
Purkyňova 115
612 45 Brno - Královo Pole
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
