How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
Hi,
the MBF announcement inspired me to check some packages that might be
relevant for me (and started fixing these). I also found some packages
where I was asking myself whether these might be interesting for anyone.
Just to give some example (maintainer in CC - Erik, its not specifically
against your package it was just some example).
The description of imgvtopgm reads:
PalmPilot/III Image Conversion utility
This program can convert, compress, and decompress up to 4-bit grayscale
images for displaying on the PalmPilot. It can take any pbm, pnm, pgm file
generated by the netpbm package and convert it into a suitable image
for the Pilot.
.
Together with netpbm many image formats, including JPEG, PNG, GIF, TIFF
and BMP, could be converted into PDB format. This can be displayed on
PalmPilot/III by viewers like "ImageViewer", "TinyViewer" or "Spec".
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. 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.
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?
Kind regards
Andreas.
[1] https://qa.debian.org/popcon-graph.php?packages=imgvtopgm
--
http://fam-tille.de
Re: How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
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.
You cannot claim a package is unused solely based on popcon data.
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.
> 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.
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"?
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 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.
It is not a problem for us to continue shipping imgvtopgm.
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.
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.
> Kind regards
>
> Andreas.
>...
cu
Adrian
Re: How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
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 bett
Re: How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
Hi Andreas, hi all, [I'm not subscribed to d-d, the long discussions on d-p are enough for my inbox ;-), so please address me directly if I should read your reply] Am 16.03.22 um 14:11 schrieb Andreas Tille: I'm not sure whether there are any PalmPilot devices out there. At Yes, there are still such devices out there. least the actual *votes* in popcon[1] is down to zero now. The package I would not trust popcorn at all. It is disabled at installation by default and even I does not use it. There is no *real* data base for package usage out there IMO. Even if we would have real usage count, IMO it should not be a rule to keep a package or remove it. We already have mechanism to exclude packages with serious issue from releases. For packages that are not part of one or several releases, we could ask the maintainer to fix or remove, that would be fair. was not uploaded by its maintainer for >10 years. Yes, because upstream development was finished and packaging was working so far. No need for new uploads IMO. It received an NMU by Adrian Bunk (in CC as well): I thanked Adrian for stepping in, but had in on my list, too. (Low prio, because I didn't see the "serious" on this "policy issue") Do we have any means to get rid of packages that should be rather removed from the distribution than draining resources. If the package was not part of one or two releases and maintainer (or any other dev) have no interest to fix it, I would agree. If you use the popcorn count to decide this I would strongly disagree. Best regards, Erik
Re: How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
Hi Erik, Am Sat, Mar 19, 2022 at 08:37:28PM +0100 schrieb Erik Schanze: > Am 16.03.22 um 14:11 schrieb Andreas Tille: > > I'm not sure whether there are any PalmPilot devices out there. At > > Yes, there are still such devices out there. Thanks a lot for your insight. > > least the actual *votes* in popcon[1] is down to zero now. The package > > I would not trust popcorn at all. It is disabled at installation by > default and even I does not use it. There is no *real* data base for > package usage out there IMO. > > Even if we would have real usage count, IMO it should not be a rule to > keep a package or remove it. As I said to Adrian in my other mail: My argument was not only based on the absolute number of the usage statistics. I was basing it on the the curve going down to zero and > We already have mechanism to exclude packages with serious issue from > releases. For packages that are not part of one or several releases, we > could ask the maintainer to fix or remove, that would be fair. Sure. That's why I kept you in CC. Please also note that I was asking a general question that should not sound like a "lets remove imgvtopgm" suggestion. > > was not uploaded by its maintainer for >10 years. > > Yes, because upstream development was finished and packaging was working > so far. No need for new uploads IMO. My point was that there are teams inside Debian (like reprocucible builds or crossbuilding like bug #989953) who file bugs with patches to a lot of packages. I personally think we should somehow help them to spent their energy on packages that are worth it. > > It received an NMU by > > Adrian Bunk (in CC as well): > > I thanked Adrian for stepping in, but had in on my list, too. (Low prio, > because I didn't see the "serious" on this "policy issue") I disagree here: If there is some "policy issue" a package should be fixed soonish. Otherwise you put burden on your fellow developers (thanking them for this is nice for sure) but delaying even simple fixes that are creating "noise" in QA channels is not a good idea. > > Do we have any > > means to get rid of packages that should be rather removed from the > > distribution than draining resources. > > If the package was not part of one or two releases and maintainer (or > any other dev) have no interest to fix it, I would agree. > > If you use the popcorn count to decide this I would strongly disagree. I'd like to repeat that I did not used popcon *count* as argument but popcon *history curve" and way more importantly the main description of the package. If your insight into the user base says that it is used I might check for another example - but my question how we could save some of our teams from working on packages that are not needed any more remains. Kind regards Andreas. -- http://fam-tille.de
Re: How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
Hi, Quoting Andreas Tille (2022-03-21 11:55:09) > Am Sat, Mar 19, 2022 at 08:37:28PM +0100 schrieb Erik Schanze: > > Am 16.03.22 um 14:11 schrieb Andreas Tille: > > > was not uploaded by its maintainer for >10 years. > > > > Yes, because upstream development was finished and packaging was working > > so far. No need for new uploads IMO. > > My point was that there are teams inside Debian (like reprocucible > builds or crossbuilding like bug #989953) who file bugs with patches to > a lot of packages. I personally think we should somehow help them to spent > their energy on packages that are worth it. personally, when doing work that affects multiple packages, I concentrate on those that are in unstable *and* in testing. In my experience this weeds out 99% of those source packages that I really shouldn't bother with. I heard from others that they use the same heuristic to spend their QA time on packages that will likely make it into the next stable release. During my last round of mass-rebuilds I unfortunately didn't apply this heuristic and stumbled across src:ants. In contrast to Andreas, I think that even packages without a maintainer upload for >10 years should *not* be kicked out of the archive even if their popcon numbers are down to zero. However, I do not understand why we do not have a mechanism to kick out source packages like src:ants automatically for good. Not because of its low (and decreasing) popcon number but because: - the last stable release the source package was part of, was stretch - its binary package was last installable during the development of buster and uninstallable since then - the source package has four open RC bugs with the *youngest* from four years ago Why do we carry essentially useless weight around for so many years? Thanks! cheers, josch signature.asc Description: signature
Re: How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
Am Wed, May 04, 2022 at 08:02:51AM +0200 schrieb Johannes Schauer Marin Rodrigues: > During my last round of mass-rebuilds I unfortunately didn't apply this > heuristic and stumbled across src:ants. In contrast to Andreas, I think that > even packages without a maintainer upload for >10 years should *not* be kicked > out of the archive even if their popcon numbers are down to zero. I'd like to stress (again) that this is not really in contrast to my opinion. I was *first* reading the description and *afterwards* checked those technical data. If the description would not have made me suspicious I would not have asked that question. Since probably nobody with QA interest is reading the description of packages regularly we might need to go the reverse route to find removal candidates. (If someone needs another proof that I do not really want to kick imgvtopgm I agreed with Eric to do a team upload of this package into the Debian Photo team once netpbm has passed new. ;-) ) > However, I do not understand why we do not have a mechanism to kick out source > packages like src:ants automatically for good. Not because of its low (and > decreasing) popcon number but because: > > - the last stable release the source package was part of, was stretch > - its binary package was last installable during the development of buster > and >uninstallable since then > - the source package has four open RC bugs with the *youngest* from four > years >ago > > Why do we carry essentially useless weight around for so many years? I fully subscribe your question and think we should maintain a list of those removal candidates (which can be easily obtained from UDD). Kind regards Andreas. -- http://fam-tille.de
