Emilio Pozuelo Monfort wrote...
> I would suggest to come up with some algorithm to determine if a package is
> effectively unmaintained, and implement it in an automatic way that gives
> maintainers prior notice and a chance to react, like we do with auto-removals.
> Then if nothing happens in a reasonable time frame, the package gets orphaned.
This seems very reasonable, go for it. Such an approach would also
ease QA uploads for packages and should overall improve package
quality.
It is quite disturbing to see how many packages dropped out of stretch
due to the three big migrations (gcc-6, openssl 1.1, debhelper), even
if fixing it would take less that an hour. Also, in spite of all the
work the people behind them did, including long grace periods. So we
have a lot of de-facto orphaned packages and it's about time to make
such a status official sooner.
FWIW, I consider salvaging several packages that are debhelper compat
level 4 or earlier. But I always wondered whether this wasn't a good
time to go beyond the bare necessities and do all the good things in
packaging that were introduced in the past ten years, like dh7 style
debian/rules, 3.0 (quilt) source format, machine readable
debian/copyright etc.etc. - although this is rather QA work than NMU.
But assuming the package is technically unmaintained, why not do work
that has to be done anyway and will help a future maintainer?
> I think we should also have an auto-removals-from-sid[1]
(...)
> [1] With a *very* conservative criteria. We don't want to remove a package from
> the archive after 30 days because of 1 RC bug.
Not so sure about this.
There still might be folks around that find that particular package
useful for their work. In an ideal world they'd let us know. In real
life I've experienced they are not sure about the procedures and are
always happy to meet a Debian guy so they can tell about their
concerns. My usual answer "File a bug, it's just an e-mail, you won't
get eaten for small mistakes in form" sometimes worked, often it was
better I took care of that myself. So we (as in Debian) suffer from
the usual problem of not getting enough feedback, having to guess.
Therefore, in case of doubt, rather keep a package.
Also resuming work on a existing though pretty broken package is a
lower bar then doing the re-entry procedure.
To add a few criteria, I'd remove a package from sid only if it
* is plain broken
This means the code, not the packaging.
* (no longer) serves a reasonable purpose
If a package is specific for a task or feature that is no longer
supported (think set6x86 which was for CPUs that are now pretty
old), there is no reason to keep it.
* no longer exists in older supported distributions
Since still users might not learn their package is no longer part of
the now-stable until they upgrade.
* has been orphaned for a longer time, say: a year
So again users of that package had a grace period to ask for work on
that package.
Personally, I'd also appreciate notifying debian-devel about an
upcoming removal from sid, somewhat similar to ITPs, so there's a last
chance for any interested party to pick the package.
And there's still the shortcut using RM:
Christoph
Attachment:
signature.asc
Description: Digital signature