On 11/14/18 10:36 AM, mcatanzaro@xxxxxxxxx wrote:
We need to rebase GNOME within about two months of the new upstream releases, or we'll lose our edge with the GNOME community. We'd be ceding our position as best GNOME distro to Ubuntu and Arch.
It seems wrong that a DE, even if it's the default, has so much sway over the distro as a whole. I use Fedora for so much more than a desktop. Admittedly, I've never been a big fan of spins and would much prefer to see all DEs and other spin-like things just be more rpms I can install, if I choose ... all on top of a single base OS.
So a one-year cycle means a major GNOME version update will need to land in the middle of a release to avoid that. And these do not have a good reputation for stability. Basically we'll wind up with a bunch of bugs landing halfway through the release, and without the usual Fedora QA process to ensure the most important of them get fixed before they reach users.
Why can't GNOME be updated mid-release like any other application? Why does the QA process require the cadence of the whole distro release process to bend to GNOME? Can't a major GNOME update land in the testing repos to have QA issues sorted out there just as well as in some alpha/beta release of the overall Fedora?
I would think that the distro release cadence only have hard limits set by things like the kernel and glibc. I'm probably taking an entirely too simple view of the overall process and am not attacking GNOME specifically, but just as an example given your comment. I'm just genuinely trying to understand the reasoning behind it and see if those assumptions cannot be changed.
I'd love to see Fedora move to a one year release, but with a 6 month upgrade period (N and N-1 for 6 months vs the present N, N-1 and N-2 for 1 month). I'd think that would mean less work for maintainers and provide nearly the same or better benefit to users as what we have now.
_______________________________________________ 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
