On Tue, 2024-12-24 at 09:15 -0500, Ben Beasley wrote: > I agree with the plan, but I wanted to note that deprecating a package > that other packages depend on requires a FESCo-approved Change[1]. > > (It is weird that the deprecation policy is so much more bureaucratic > than the retirement policy. By comparison, I don’t know of any policy > that would forbid summarily retiring a package that others depend on. > It’s a bad practice, and one might be asked to allow someone else to > unretire and maintain the package if the consequences are bad enough, > but I’ve never seen a blanket policy against it.)
I'd suggest we amend the retirement process to specify that if the package-to-be-retired has any dependencies, it must go through the deprecation process first. I suspect the retirement process as written is kinda written with the assumption that the package being retired is already 'useless' (it does say "In case the package is no longer useful for Fedora, e.g. because it was renamed, or upstream does not exist anymore, then it should be retired"). The 'deprecation' process I think resulted from a couple of cases of very significant things like network-scripts getting deprecated. Perhaps we need some kinda middle ground, but it's a bit hard to express "if it's really important, Change; if it just has a few deps in one specific area, send out emails" or something like that. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
