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 change > > > > > > True, 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-releases > > > > > It 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. 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. -- 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
