As part of the Package Retirement Process and the Default Services policy, we should add creation of a Release Notes issue at the end of each process.
The Release Notes are an important way for us to inform users of significant changes to the distribution. While neither of the above (generally) require the Changes process, they are significant enough to include in the Release Notes.
I'm not entirely sure that this shouldn't be delegated to FPC. If that's the more appropriate venue, I'll take it up with them.
How would we enforce this?
My concern would be that requiring packagers to follow https://docs.fedoraproject.org/en-US/fedora-docs/contributing/contributing-to-release-notes/ may significantly increase the process burden of retiring a package, with the following likely consequences:
If retirements belong in the release notes—and maybe they do—perhaps it would make more sense to collect a list of retirements with a script rather than requiring every packager to write documentation.
Agreed. When packagers retire a package, fedpkg retire already requires them to provide a reason for retiring it. The script can use that data to generate release notes if necessary.
fedpkg retire
An excellent question. The word "require" is doing a lot of work here. Mostly, it would be "we add it to the docs and trust that people will do all of the steps".
My concern would be that requiring packagers to follow https://docs.fedoraproject.org/en-US/fedora-docs/contributing/contributing-to-release-notes/ may significantly increase the process burden of retiring a package
I very intentionally proposed opening an issue, not writing a release notes entry. I think it's fair to let the Docs team worry about getting it into the release notes (which, admittedly, we're not particularly good at currently. The team is gaining some steam, though), but they can't do that if they're not aware of it.
I retire many packages every release, mostly because they were orphaned for 6+ weeks. If we really consider that to be a significant change to the distribution, I would prefer gathering the list automatically once and including it in the release notes than opening dozens or hundreds of tickets.
Yeah, this is another of those cases where an automatic solution sounds is much better. A script should go over all the repositories and find any that have "F(n-1) < retirement date <= F(n)" and autogenerate a list of packages along with reason taken from the retirement commit for them.
A week has passed and this has moved nowhere.
Ben, if you still think this is a good idea, I suggest maybe gathering some support for it on the devel list.
Otherwise, maybe we should look into the automation a bit.
Here's a very simple demo:
$ repoquery --repo=koji36 -a --source | pkgname | sort | uniq > 36.components $ repoquery --repo=koji37 -a --source | pkgname | sort | uniq > 37.components $ for component in $(comm -23 36.components 37.components); do echo $component; curl -sf https://src.fedoraproject.org/rpms/${component}/raw/rawhide/f/dead.package; echo; done augeas-vala Orphaned for 6+ weeks beanstalk-client Orphaned for 6+ weeks bodhi Replaced by bodhi-server, bodhi-client and bodhi-messages bristol FTBFS, dead upstream caffeine Orphaned for 6+ weeks colorize Orphaned for 6+ weeks compile-command-annotations Orphaned for 6+ weeks DivFix++ Orphaned for 6+ weeks dotnet-build-reference-packages .NET Core 3.1 is going to be End-of-Life'd on Dec 13, 2022 (see https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#lifecycle). The upstream .NET project does monthly releases to fix security issues. We shouldn't ship this package in a new Fedora version once we can no longer fix the suspected security issues. As an alternative, .NET 6 is now available in Fedora and is supported until Nov 2024 years by upstream. dotnet3.1 .NET Core 3.1 is going to be End-of-Life'd on Dec 13, 2022 (see https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#lifecycle). The upstream .NEt project does monthly releases to fix security issues. We shouldn't ship this package in a new Fedora version once we can no longer fix the suspected security issues. As an alternative, .NET 6 is now available in Fedora and is supported until Nov 2024 years by upstream. elmon Orphaned for 6+ weeks ez-pine-gpg Orphaned for 6+ weeks fbzmq abandoned upstream - see https://github.com/facebookarchive/fbzmq forbidden-apis Orphaned for 6+ weeks gap-pkg-happrime Dead upstream. Some functionality is available from gap-pkg-hap. gimp-dbp reason=Upstream no longer exists and the addon is obsolete gnome-books gnome-books is retired/archived upstream gnome-online-miners Orphaned for 6+ weeks gnome-passwordsafe Renamed to 'secrets' gnome-shell-extension-material-shell Orphaned for 6+ weeks ...
I'm not opposed to automation. Thanks for the example @churchyard. I should be able to make a reasonable script from that and run it at the start of Final Freeze. With luck, I'll even get to it for F37 :smile: (and also TIL about the comm command)
comm
I'll close this proposal
Metadata Update from @bcotton: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.