On 6/30/23 04:34, Benson Muite wrote:
There is at present no policy on when and why packages should be deprecated. Have made a proposal to allow deprecation of packages only when they fail to build or are a security concern. In other cases, orphaning and retirement should be done. Comments and suggestions for improvement are welcome.
There are other valid reasons to deprecate packages. Upstream deprecation is one of them.
For example, three of the subpackages in python-opentelemetry are currently deprecated because upstream has deprecated them, and I expect them to disappear in the future. Deprecating the subpackages keeps anyone from packaging something that depends on them and then being impacted a few months later by their removal in Rawhide.
In my experience, deprecation is used extremely sparingly (there are only 42 spec files in the entire distribution with the string “deprecated()”), and I am not aware of any issues with it being used carelessly. Furthermore, the current policy already requires a FESCo-approved change to deprecate anything that has dependent packages.
I am not convinced that the proposed Change clearly or accurately reflects all of the valid uses for deprecation, nor am I convinced that attempting to codify these uses is useful to packagers or solves an actual problem in the distribution or community.
This would also likely impact package review guidelines, since there are packages that people may want in Fedora, which build but do not have much upstream activity.
There certainly is no extant policy on how much upstream activity a package needs to have to enter or remain in Fedora, nor do I think it is reasonable to regulate this on anything other than a case-by-case basis. There are decades-old scientific tools with deceased authors that are still perfectly useful, there are tools that are “done” but have upstreams that spring into action after ten years of quiescence if a new bug is found, there are network libraries with large attack surfaces that might cause concern if an upstream PR or issue languishes untriaged for a few months, and there is everything in between.
The document https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/ already warns about the added maintenance burden of packaging projects with inactive or absent upstreams, and it is reasonable for a package reviewer to warn the submitter about an inactive upstream. It still makes sense to package these projects when they are sufficiently useful or when good alternatives are not yet available.
_______________________________________________ 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
