Hi Adrian,
Am Wed, Mar 16, 2022 at 10:48:12PM +0200 schrieb Adrian Bunk:
On Wed, Mar 16, 2022 at 02:11:09PM +0100, Andreas Tille wrote:
...
I'm not sure whether there are any PalmPilot devices out there. At
least the actual *votes* in popcon[1] is down to zero now.
This is less convincing than it sounds, since popcon data is based only
on a tiny and non-representative fraction of our users.
I'm fully aware of this.
You cannot claim a package is unused solely based on popcon data.
The idea that we possibly do not need the package was the description
that it was supporting PalmPilot. After I have read that description
I checked the popcon graph which had some peak and went to zero now
(based on the votes with some remaining installs).
Debian Med also has packages with zero popcon votes, users of software
for exotic/ancient hardware or uncommon usecases (like Debian Med) are
not generating high popcon numbers.
This is the reason why I think I can interpret popcon stats. Its a
different thing to have a high usage number which goes down or whether
the usage is low in general. Its also a different thing whether
software is used in setups (some institutions running clusters) which
have a tendency to not activate popcon. I can not see this reason for
the said example package.
BTW, please do not read my mail as: Lets remove imgvtopgm. I simply
found this example and used it to stear a discussion about the general
fact.
The package
was not uploaded by its maintainer for >10 years. It received an NMU by Adrian Bunk (in CC as well):
[2022-01-02] imgvtopgm 2.0-9.1 MIGRATED to testing (Debian testing watch) [2021-12-27] Accepted imgvtopgm 2.0-9.1 (source) into unstable (Adrian Bunk)
[2011-02-23] imgvtopgm 2.0-9 MIGRATED to testing (Debian testing watch) [2011-02-13] Accepted imgvtopgm 2.0-9 (source i386) (signed by: Erik Schanze)
The changelog of that NMU was:
* Non-maintainer upload.
* debian/rules: Add build-{arch,indep}. (Closes: #999003)
From my naive perspective this package caused some work from a quite
busy maintainer for no obvious user base. May be I'm wrong in this specific case but this observation raises my question: Do we have any means to get rid of packages that should be rather removed from the distribution than draining resources.
You are getting it wrong what was draining the resources.
It was not the package that was draining the resources,
it was the MBF that was draining the resources.
Do you mean the "build-{arch,indep}" MBF or the current one about
source format 1.0?
And these MBFs usually fail to make a convincing case that the benefits
are worth all the resources that are drained by the MBF.
If the answer is no should we possibly use the list of packages that are not topic of the heated debate around the source format 1.0 (where maintainers are obviously are caring about their packages just disagree with format 3.0 format) to pick some packages that should be rather
removed than fixed?
How do you define "rather removed"?
Well, if you was happy to do your upload than it should rather not be
removed.
According to the BTS there was and is no known user-visible problem in
the package that needed or needs fixing in the package you are using
as example.
I agree with the "not user visible". However
#989953 imgvtopgm FTCBFS: builds for the build architecture
Tags: patch
Date: Wed, 16 Jun 2021 15:09:02 UTC
is unanswered since half a year. So some other developer has spent time
into it. I *personally* try to reward the work of my fellow developers
by uploading that patched package as soon as possible.
I am still a regular user of my 15 year old iPod, and I was pretty
annoyed when I had to do an emergency adoption (changing nothing but the maintainer field) of a package I use for it after seeing that someone
thought it would be a good idea to do "RM: RoQA; Upstream not active, orphaned".
As DD I can do that if I notice, the average user cannot do anything and won't even notice until the next release in 1.5 years.
I do consider it a regression when we no longer ship a package in a
release that was in the previous Debian release.
We do agree here. That's why I was honestly asking whether we have /
want to establish some sensible means to get rid of packages that are
somehow draining more time from developers who could serve our users
better by caring for other packages.
It is not a problem for us to continue shipping imgvtopgm.
I agre that it is not a problem and I did not said so.
And that's why I'd like to see a case made why it is better for our
users when a package is no longer shipped.
Since more and more packages that are unused are draining time from
teams like reproducible builds team, porters team, may be security team
that could be spent better on other packages. I've picked from the
source 1.0 MBF list a couple of packages that were lacking developer
attention and since I considered them worth keeping I've simply spent
that time. But I also stumbled upon packages where I'm not willing
to spent time on.
It might or might not be possible to make the case for removal of this specific package, but "low popcon" or "abandoned upstream" alone are not convincing points.
You said above that I'm perfectly aware of those "low popcon" or
"abandoned upstream" packages in the Debian Med team and I'm the last
one who would consider this convincing points. My main point was the
"supports device that no user is using any more" and I tried to make
this point by the *full* popcon graph (may be not stressed explicitly
enough) and even more importantly the package description.
To make at least some constructive suggestion what could be acceptable
for users: What about adding some debian/NEWS.Debian explaining that
this package will be removed in the next+1 stable release and file a
bug report about this. Users who see this message could answer to
the bug report and ask for not removing it.
I'm not sure whether this overhead might drain more time from developers
that currently is spent (and that's actually the point I want to make).
I somehow came to the conclusion that having a continously growing
package pool requires means to get rid of things that are there just
because they were there at some point in time. And for sure the
maintainer of the package should have a say about this but we should
also find a way to deal with cases if the maintainer does not raise any opinion.
Kind regards
Andreas.
--
http://fam-tille.de
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)