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 <lruzicka@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.is@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-leave@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

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka@redhat.com   



--

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka@redhat.com