Sorry about the two lines of the letter that do not fit much into the
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,
On Wed, Nov 28, 2018 at 10:20 AM Lukas Ruzicka <lruzicka(a)redhat.com> wrote:
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.
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> 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:
FEDORA QE, RHCE
612 45 Brno - Královo Pole
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
612 45 Brno - Královo Pole
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <