#11994 Retired packages are not properly marked in Pagure
Opened a year ago by vondruch. Modified a year ago

When package is retired, it should be marked as retired/unmaintained in Pagure. E.g. this is recent example of successfuly retired package:

https://src.fedoraproject.org/rpms/rubygem-rails-deprecated_sanitizer

However, libxslxwriter which was retired by proven packager is not marked as such.

Another example of such package can be this:

https://src.fedoraproject.org/rpms/pcmciautils


Where exactly do I see a package in src.fp.o is retired?

rubygem-rails-deprecated_sanitizer is orphaned and retired on rawhide

libxslxwriter is not orphaned, only retired on rawhide

Oh, I found a Retired button on the left where orphaned-only packages have the Take button.

Packages that are retired but not orphaned don't have it. I guess It makes sense to add it there.

TBH, I don't find the status "retired but not orphaned" very useful. Especially in the libxslxwriter case.

"retired but not orphaned" generally makes sense. e.g. I still maintain this on f39: https://src.fedoraproject.org/rpms/python-cython0.29

Once all branches are retired, packages get orphaned automatically. Technically, libxslxwriter is still "maintained" on f39 and f40 (the fact that this package was never actually maintained makes it a bad example).

Technically, e.g. pcmciautils is unmaintained for ages (and @harald should have been called unresponsive maintainer instead of forcibly retiring his packages).

Technically also rubygem-rails-deprecated_sanitizer should be maintained in F38 / F39. And also with a help of proven packager, it is still possible.

IMHO, there should be no difference between packages retired by somebody and by "orphaned" packages process.

It is reasonably common for me to retire packages (because of renaming, upstream reorganization, packages with long-dead upstreams finally becoming leaves, and so on), while still fully supporting stable branches. Usually no active maintenance is required, but in these cases I still want to be assigned and act on any bug reports for stable releases, and perhaps even provide security/bugfix updates if applicable.

One example is libmetalink, which I’m planning to retire in F40 and F41 after the Beta Freeze lifts. It has been obsolete and unsupported upstream for over ten years, but it’s also a dependency for wget. With the retirement of wget as part of Wget2asWget, I can finally retire libmetalink – but that doesn’t mean I am not willing to take care of the existing branches. I suspect the attitude of the wget maintainers toward the now-retired wget package is similar.

Metadata Update from @phsmoura:
- Issue tagged with: investigation, low-gain, low-trouble, ops

a year ago

Log in to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog