On Thu, 2022-11-24 at 07:34 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Nov 23, 2022 at 04:04:59PM -0800, Gordon Messmer wrote: > > In the wild, I often see Fedora described as a "semi-rolling" release. As a > > policy matter, the distribution promises to be mostly stable, but I find it > > increasingly hard to honestly present it as such. > > > > As a couple of quick examples, I'd point out that in Fedora 35, Blender > > updated from 2.93 (an LTS version) to version 3. In Fedora 36, Emacs > > updated from version 27 to 28. I've read in the KDE Matrix channel that KDE > > will be updated in Fedora 36 to 5.26, even though it has already been > > updated from 5.24 -> 5.25 (my reading of the KDE update policy is that > > Fedora used to update all releases with every KDE release, but decided to > > stop). Firefox and Thunderbird get updates in most releases, even when they > > contain API-breaking changes (those really should have an explicit > > exception, IMHO.) I could offer more, but my point is simply that examples > > of updates in prominent packages isn't hard to find. > > FWIW, I was sure that we have an explicit exception for Firefox. But > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#exceptions-list > doesn't list it. > > Yeah, I think that the way updates are managed has in practice changed a lot. > This is at least partially caused by the slow change in relationship between > upstreams and our packaging: the distro is inching ever closer to being a > thin delivery mechanism for upstream code and upstream build system and > upstream packaging decisions and upstream release cadence. Even a few years > ago it was fairly common for the packaging to be a big affair with tweaks > to the upstream build system or even a completely custom build, downstream > patches, and many modifications to the final layout. There still are packages > like this, but less and less. If the upstream is sane, there is no need to > deal with any of that. > > Another aspect that has changed is that many upstreams are better at keeping > backwards compatibility. E.g. in Rust and Python ecosystems, semver is now > the norm, and in my experience the associated understanding that breaking API > is bad is more widespread. So there are less reasons for us not to update. > At the same time, software is ever more complicated and moves ever faster, > so maintaining multiple versions in parallel is a lot of work. > > Combining all that (bigger and more complicated packages, saner upstream > updates, and our packaging being closer to upstream), just makes it less > work for the packager to release the same upstream version in all Fedora > releases. > > Then there's the aspect that for fast-moving software, the latest version > may be the only usable version. > > > That's not necessarily to object to those changes (though I did have to do > > some minor fixes after the emacs update, and I grumbled quietly), and I > > don't want to disrupt users getting new features if that's what everyone > > actually wants. But, it does bother me that the documentation doesn't seem > > to reflect reality. I think that the documentation should offer users a > > realistic expectation of what they'll get from Fedora. > > > > Does anyone else feel like the documentation should be updated, or am I > > making too much of this? > > I think the documentation should be updated to follow the changing practice. > I'd change the policy to allow packages to update to latest versions > if deemed the best option by the maintainers. (Guidance when it is > actually the best option would need to be provided too of course.) Well, I find your mail interesting, because...I agree with most of the first paragraph, but at the same time, none of that is really in conflict with the existing update policy as I read it. The update policy is very keen on discouraging *compatibility-breaking* updates. However it already allows exceptions when updating to a new major release is necessary to maintain security (i.e. upstream doesn't provide stable branches with security fixes, and backporting downstream is too difficult). The thrust of your argument is that the F/OSS ecosystem as a whole has gotten better at doing updates that don't break compatibility. It's not against the current policy, as I read it, to ship such updates, so it doesn't really need any updating on that view... On the whole, I'd say the policy is still sensible as-is, but it's always been something that's kind of applied on request, like city bylaws tend to be. If your garden fence is against the bylaws but none of your neighbours complain, you'll probably get away with it. If you update your package to a new major release but everyone who uses it is fine with that, you'll probably get away with it...we tend to only invoke the policy when an update gets "flagged" by negative feedback or a failed test or whatever. I also have a confession like msuchy's: I don't follow the policy for openQA. None of the approximately three other people who actually use the Fedora openQA package has ever complained about that, so I think I'm getting away with it...:D Going back to Gordon's original examples: I think Firefox should be documented as having a permanent exception here, there is obviously no other sensible policy for it. The Blender and emacs cases could use looking into, it'd be interesting to hear what the maintainers say. The KDE wiki page should probably just be changed - KDE maintenance has turned over a bit lately and got more active and the current maintainers probably just didn't know/remember to update that page to current practice. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
