On 6/30/23 17:05, Ben Beasley wrote: > 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. > Deprecation due to upstream deprecation is reasonable. Would be great to have this in such a policy. > 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. > Aspell was recently deprecated due to lack of recent activity upstream. It would be good to have guidance for deprecation vs. orphaning. The deprecation process does provide advance notice of an action which orphaning does not. Advance notice is good to have where possible for packages with many dependencies or a wide user base. >> 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. Essential crypto libraries have greater review. > > 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. > The recommendations made are reasonable. _______________________________________________ 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
