Dne 24. 11. 22 v 22:42 Adam Williamson napsal(a):
On Thu, 2022-11-24 at 16:26 -0500, Stephen Smoogen wrote:On Thu, 24 Nov 2022 at 13:12, Gordon Messmer <gordon.messmer@xxxxxxxxx> wrote:On 2022-11-24 03:13, Michael J Gruber wrote:I guess there's (at least) two ways to understand "stable": - things don't break - things don't changeTrue, but the policy document is explicit about which meaning is intended, reading, "Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience" https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releasesIt has to do with differing opinions on that and in the first part of the sentence. There is A) Updates should aim to fix bugs, AND not introduce features. B) Updates should aim to fix bugs, and not introduce features. Reason A with a strong logical AND means that things should be backported for any bug fix. In this case, you are probably never going to see any bug fixes occur in the distro as most software projects will say that the bug is only fixed in the latest version which of course added 9 features. Since this is usually a large amount of work for someone who may only have taken the package to keep it in for a dependency, you would then just see those fixes in rawhide (if at all). Reason B with a weak language 'and' means that you shouldn't do updates just to introduce new features but in order to fix things. This means that if the upstream which in the cases of Firefox, Thunderbird, emacs, GIMP, etc are either a package set they say is LTS OR in the latest.. you are going to see updates occur. Whenever I have talked to FESCO members over any large change, they have said it was the B form they meant and they were ok with updates if it was the way to fix things.Thinking it over some more - I think Gordon's right that I hadn't considered all the language - I think my personal opinion would be that the policy should be adjusted to be less opinionated on this idea of "introducing features", and concentrate more on "unexpected changes to the user experience". There are a lot of cases where introducing features is entirely benign, after all. If a CLI tool I use grows a useful extra option while still supporting all the ones it had before and behaving in the same way when using those, that just does not seem like something to be concerned about. I'd happily send such an update to stable.
While I agree with the above, the update on itself is not free. It cost time. It cost bandwidth. And it sill might introduce breakage.
Vít
If the update *removes* some existing argument, or changes the behaviour of one, that's much more significant. This is really kinda the rule about API/ABI changes, only for applications, in a way. Adding new functions to a library doesn't change the API, only removing or changing the behaviour of existing ones.
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
