On 11/14/18 4:38 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Nov 14, 2018 at 12:37:46PM -0500, John Florian wrote:
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.
It's not just gnome. It's also gcc, glibc, boost, systemd, python, and
any other project which cannot be upgraded easily mid-cycle. Having
a chance to push a new version every six months is much better than
waiting a year.
I still don't understand what makes updating these for a *new* release
significantly easier than an *existing* one. So let's just say GNOME
(or whatever) comes out next month with a new major release we want to
showcase. Why is it necessary to have a Fedora 30 to be able to realize
this update. What is so difficult about providing this for Fedora 29.
I'm trying to understand why these upstream updates can't be decoupled
from the Fedora release schedule.
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?
For me, any discussions about .1 or .5 completely miss the point.
The numbering does not matter at all, the freeze and the testing and
bugfixing matters. If we do it every 6 months, we might just as well
call this a new release each time.
As mentioned elsewhere in this thread, we have plenty of technical
issues to solve, including security bugs and whatnot. Let's not get
distracted by numbering.
I agree the numbering is irrelevant... I never said it was. It was said
or implied that QA works better *between* releases and I don't see why
that cannot occur for a release that's already out the door. I mean
isn't that what the testing repos are for? So I'm proposing to partly
evolve to a sort of rolling distro. If the schedule decoupling can
occur, it should then be possible to move Fedora to a yearly release
schedule, provide a 6 month upgrade window and reduce maintainer burden
because there's only 1 or 2 supported releases instead of 2 or 3. That
would mean releases are supported for 18 months instead of 13. Change
the periods how you wish, but the decoupling would allow getting longer
support while requiring less work due to fewer concurrent releases.
_______________________________________________
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
