--=-=-=
Content-Type: text/plain

Hi,

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up,
including no longer installable packages.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

I would also like to do something similar to unstable; maybe start with packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

Ansgar

--=-=-=
Content-Type: text/plain
Content-Disposition: inline; filename=trash-experimental.txt Content-Description: Removal candidates for experimental

projectb=> select s.source, s.created from source s
where exists (
select 1 from src_associations sa
where s.id = sa.source and
sa.suite = (select id from suite where suite_name = 'experimental')
)
and s.created < '2020-01-01' order by source;
source | created -----------------------------------+-------------------------------
android-platform-external-doclava | 2019-07-24 21:08:04.691192+00
critterding | 2014-11-03 01:19:08.643578+00
darkice | 2019-03-24 11:18:56.087124+00
dtc | 2012-06-08 09:17:11.189323+00
go-cpe-dictionary | 2018-12-26 05:34:06.439036+00
golang-github-golang-geo | 2017-03-09 15:19:27.388525+00
golang-golang-x-debug | 2017-03-23 09:03:43.615567+00
gv | 2019-03-09 20:41:24.058607+00
imip-agent | 2019-01-06 13:34:33.740546+00
libewf | 2018-12-28 20:47:47.223343+00
librep | 2018-08-25 05:34:08.814689+00
libtaverna2-server-java | 2013-11-24 21:20:33.311726+00
libvirt-tck | 2011-11-13 15:07:12.072289+00
m2m-aligner | 2016-04-12 10:38:28.348764+00
markdown | 2019-12-28 20:57:03.304098+00
mediagoblin | 2017-08-28 13:19:49.32023+00
mitlm | 2016-04-24 16:23:21.734803+00
monkeysphere | 2019-05-19 23:33:52.925219+00
musescore-snapshot | 2019-07-05 00:19:11.735843+00
node-solid-jose | 2019-09-27 10:05:56.642068+00
node-trust-jwa | 2019-02-04 04:36:38.354632+00
nvidia-texture-tools | 2016-05-18 10:32:37.829021+00
openhft-chronicle-bytes | 2018-09-14 06:04:31.457889+00
openhft-chronicle-network | 2018-09-17 03:51:04.998927+00
openhft-chronicle-threads | 2018-09-15 20:35:37.601005+00
openhft-chronicle-wire | 2018-09-16 17:50:13.421894+00
partman-swapfile | 2019-03-12 04:54:30.304068+00
phonetisaurus | 2016-05-05 16:29:26.102649+00
php-sabre-event | 2015-11-06 01:20:46.165676+00
php-sabre-vobject | 2016-04-07 01:48:57.375779+00
pluto-sat-code | 2018-03-01 22:06:10.485772+00
poti | 2013-01-14 14:47:46.613882+00
quasselc | 2017-01-14 21:36:32.548429+00
ruby-devise-i18n | 2019-06-03 15:34:25.854689+00
ruby-nmatrix | 2016-03-03 15:26:31.250004+00
sawfish | 2019-07-19 15:35:40.94432+00
subethasmtp | 2017-12-21 12:43:37.751214+00
sump-logicanalyzer | 2011-07-27 07:17:07.488676+00
tcltk-defaults | 2019-02-24 20:54:53.737672+00
tinysvm | 2013-02-16 13:48:04.758297+00
urjtag | 2016-12-14 21:36:28.988139+00
vuls | 2019-06-18 23:16:21.087982+00
yamcha | 2017-09-25 21:34:17.955363+00
yorick-optimpack | 2017-01-08 07:03:14.977687+00
(44 rows)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline; filename=trash-experimental-dd-list.txt Content-Transfer-Encoding: quoted-printable
Content-Description: Removal candidates for experimental (dd-list)

Andrea Pappacoda <[email protected]>
markdown

Andreas Tille <[email protected]>
critterding (U)

Android Tools Maintainers <[email protected]>
android-platform-external-doclava

Antoine Beaupré <[email protected]>
monkeysphere (U)

Bernhard R. Link <[email protected]>
gv

Christopher Hoskin <[email protected]>
subethasmtp

Cédric Boutillier <[email protected]>
ruby-nmatrix (U)

Daniel Kahn Gillmor <[email protected]>
monkeysphere (U)

David Prévot <[email protected]>
php-sabre-event (U)
php-sabre-vobject (U)

Debian Go Packaging Team <[email protected]>
go-cpe-dictionary
golang-github-golang-geo
golang-golang-x-debug
vuls

Debian Go Packaging Team <[email protected]>
vuls

Debian Install System Team <[email protected]>
partman-swapfile

Debian Java Maintainers <[email protected]>
openhft-chronicle-bytes
openhft-chronicle-network
openhft-chronicle-threads
openhft-chronicle-wire

Debian Javascript Maintainers <[email protected]>
node-solid-jose
node-trust-jwa

Debian Libvirt Maintainers <[email protected]>
libvirt-tck

Debian Multimedia Maintainers <[email protected]>
mediagoblin

Debian PHP PEAR Maintainers <[email protected]>
php-sabre-event
php-sabre-vobject

Debian Privacy Tools Maintainers <[email protected]>
monkeysphere

Debian QA Group <[email protected]>
markdown

Debian Ruby Extras Maintainers <[email protected]>
ruby-devise-i18n
ruby-nmatrix

Debian Science Maintainers <[email protected]>
critterding
yorick-optimpack

Debian Security Tools <[email protected]>
libewf

Debian Tcl/Tk Packagers <[email protected]>
tcltk-defaults

Emmanuel Bourg <[email protected]>
openhft-chronicle-bytes (U)
openhft-chronicle-network (U)
openhft-chronicle-threads (U)
openhft-chronicle-wire (U)

Francesco Paolo Lovergine <[email protected]>
tcltk-defaults (U)

Gabriele Giacone <[email protected]>
critterding (U)

Geert Stappers <[email protected]>
urjtag

Giulio Paci <[email protected]>
m2m-aligner
mitlm
phonetisaurus
tinysvm
yamcha

Guido Günther <[email protected]>
libvirt-tck (U)

Jameson Rollins <[email protected]>
monkeysphere (U)

Jelmer Vernooij <[email protected]>
quasselc

Jochen Friedrich <[email protected]>
darkice

Jonas Smedegaard <[email protected]>
imip-agent
mediagoblin (U)
node-solid-jose (U)
node-trust-jwa (U)

Jose M Calhariz <[email protected]>
librep
sawfish

Kai-Chung Yan <[email protected]>
android-platform-external-doclava (U)

Kai-Chung Yan <[email protected]>
android-platform-external-doclava (U)

Lennart Weller <[email protected]>
nvidia-texture-tools

Marc Bigler <[email protected]>
darkice

Mathieu Parent <[email protected]>
php-sabre-vobject (U)

Matt Kraai <[email protected]>
markdown

Michael Stapelberg <[email protected]>
golang-github-golang-geo (U)
golang-golang-x-debug (U)

Nobuhiro Iwamatsu <[email protected]>
go-cpe-dictionary (U)
vuls (U)

ownCloud for Debian maintainers <[email protected]>
php-sabre-event (U)

Pierre Chifflier <[email protected]>
libewf (U)

Samyak Jain <[email protected]>
ruby-devise-i18n (U)

Sergei Golovan <[email protected]>
tcltk-defaults (U)

Steffen Moeller <[email protected]>
libtaverna2-server-java
pluto-sat-code
sump-logicanalyzer (U)

Thibaut Paumard <[email protected]>
yorick-optimpack (U)

Thomas Goirand <[email protected]>
dtc

Thorsten Glaser <[email protected]>
musescore-snapshot

Uwe Hermann <[email protected]>
urjtag

Vincent Danjean <[email protected]>
poti

Yannick Heinrich <[email protected]>
sump-logicanalyzer

--=-=-=--

--==-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iIgEARYKADAWIQR3hZU8YXPYylUJRxfDof4h+X+qzwUCZ3E73BIcYW5zZ2FyQGRl Ymlhbi5vcmcACgkQw6H+Ifl/qs8H7AD7BkS7pMwV0/w9Kt1KvvYXVvqWNxUQmdXX EBoL7WNZiWoA/0nzUxvTpP/mWDu2Bm9k7TZVjxxeNjnh5zwYHny6ZjIB
=klfg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Date: Sun, 29 Dec 2024 13:37:50 +0100
From: Matthias Geiger <[email protected]>
To: <[email protected]>, <[email protected]>
Cc:
Bcc:
Subject: Re: Remove ancient uploads from experimental (and later
unstable)
In-Reply-To: <[email protected]>

Hi,

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

Sure, seems like a sane choice. If a package has been in exp for 2+
years and never has been uploaded to unstable it's likely been "forgot".
As experimental is a staging ground for packages I agree it should be periodically be checked for outdated cruft(where the date is > 2 years).

best,

werdahias

Please CC me as I am not subscribed to the list.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

This is a very good idea.

I would also like to do something similar to unstable; maybe start with packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

This one deserves some discussion but is also a good idea. It was also
proposed recently in https://lists.debian.org/debian-devel/2024/08/msg00298.html


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdxSrEtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 5iQP/2rrdUy05kMDtOOBFyB8CAEPPljTmGLzSNcOlVOYAt3ObLfbK/OxjN0M3ROR q0/vanBuBZaiqUxzqtRvdIJEFyYxB2Z3MSOXwftxoTP/teil+L+bcVAE2oEJGo9V 9l307KDgmgOoQjHUaLCrRF2Z5fxVtE7yh4azEEQIgWkXVZXDbJmlKttTkXljmYYt 2sEpu9Wam2jJLVv2YH0ad1LaAH0KDmUNn9ufvD451JEJ1z31gFHj8bc087EQ+C3L sLHcjtpRjOQu4MS16xdR4szE+nMWcIEMunl3HQ7IevunB55aVAxiV/idtBIxdwNt LdgWsMGRq2Sf42feMHm0i+na1lh3cRnN98Vk8+H+CxlUSDb2uLmYdyM3eiFXXIp3 P3a12A6p3DGV0YUCqpXYQKc8V3MIIu+ap8oQM/+Asug0RDCNg5nmHx7CYj0JVSsp l3cy0mCKcpHDi+ysgijefs6aD9AVWQiV9horORisgYclqwy30GPDbPdY2NX1seWC T9PqO9ghF7i7vtol1CFF8aeQpsIR+8KrVhX7MRmRLHdNN1byaMDeu2iLy2v60WRF HhE6SAMdMk8bogN78ohJ+xIj94da3Sct6LKcMDbeV9kqbK+h2jEMy5rYyPdCFBVf bX/FVI5hgath4M71R5R26aWNOA4dHLrdVym7h7xd4GuzseW8
=b2Ev
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 29/12/2024 13:08, Ansgar 🐱 wrote:
[…]

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

Yes please.

David Prévot <[email protected]>
php-sabre-event (U)
php-sabre-vobject (U)

Ouch, you have my consent on these.

Regards,

taffit

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ansgar dixit:

musescore-snapshot | 2019-07-05 00:19:11.735843+00

I do have plans to pick that up once I find the tuits for it
and have finished the preceding musescore{2,3} uploads. (Lots
to do there.) So please keep that for now.

Thanks,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ansgar,

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

Thanks for cleaning up the archive. The proposed criteria vaguely makes
sense to me for experimental, but not as much for unstable.

I would also like to do something similar to unstable; maybe start with packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

I earlier proposed unstable removals and am now operating a
semi-automatic unstable auto remover. Its semantics are as follows.

Consider packages that have an rc bug in unstable that hasn't been
interacted with within one year and where the package in question is not
part of stable nor testing and is not a key package. For each of those
packages file an important removal suggestion bug. Reassign such bugs to ftp.d.o as RM/RoQA bugs to ftp after a month of idleness. This seems to
work out quite well and I removed more than 100 source packages this
way. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org&tag=sidremove
Feedback welcome.

For unstable, I think there is more reason to keep packages that have
not been uploaded in a while - so long as they do not accumulate rc
bugs.

monkeysphere | 2019-05-19 23:33:52.925219+00

I removed it from unstable, and missed experimental. Do you have any
hints on how to improve the RM bug #1085868 such that experimental is
also covered?

php-sabre-event | 2015-11-06 01:20:46.165676+00

I think I also removed this from unstable. Same question.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 a écrit :

Hi,

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

Only if that does not lead to a subsequent upload of the package to be
directed to the NEW queue again. This would waste way too much time.

I would also like to do something similar to unstable; maybe start with packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

Not for some of my packages at least. As a rule do not remove packages
that do not have RC bugs, even if they are barred of entering testing.

Cheers,
Bill.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-29 Helmut Grohne <[email protected]> wrote:

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

[...]

I would also like to do something similar to unstable; maybe start with
packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

I earlier proposed unstable removals and am now operating a
semi-automatic unstable auto remover. Its semantics are as follows.

Consider packages that have an rc bug in unstable that hasn't been
interacted with within one year and where the package in question is not
part of stable nor testing and is not a key package. For each of those packages file an important removal suggestion bug. Reassign such bugs to ftp.d.o as RM/RoQA bugs to ftp after a month of idleness. This seems to
work out quite well and I removed more than 100 source packages this
way. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org&tag=sidremove
Feedback welcome.

[...]

Good morning,

I think this needs a mechanism fo excempt packages which are kept
out of testing *intentionally* with a dummy rc bug (like firefox's
#817954).

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Andreas Metzler <[email protected]> [241231 06:59]:

On 2024-12-29 Helmut Grohne <[email protected]> wrote:

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

[...]

I would also like to do something similar to unstable; maybe start with
packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

I earlier proposed unstable removals and am now operating a
semi-automatic unstable auto remover. Its semantics are as follows.

Consider packages that have an rc bug in unstable that hasn't been interacted with within one year and where the package in question is not part of stable nor testing and is not a key package. For each of those packages file an important removal suggestion bug. Reassign such bugs to ftp.d.o as RM/RoQA bugs to ftp after a month of idleness. This seems to work out quite well and I removed more than 100 source packages this
way. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org&tag=sidremove
Feedback welcome.

[...]

Good morning,

I think this needs a mechanism fo excempt packages which are kept
out of testing *intentionally* with a dummy rc bug (like firefox's
#817954).

Thats this usertag:

https://udd.debian.org/cgi-bin/[email protected]&tag=sidremove-ignore

C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

for experimental: yes, please!
for unstable: what Helmut said & does.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

I'd propose to be more "aggressive" and use 2021-08-14 as the date, IOW
the bullseye release date. 2023-06-10 (=bookworm release date) would IMO
be too agressive *now*, but fine after the trixie release.

Thanks for bringing this up; cruft like this wastes human and computing ressources regularily, so we regularily need to reduce it, as it accumulates all the time.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Bananas are berries.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmd2gIoACgkQCRq4Vgaa qhwIaA//Z/op89oiHIrzS/NZJeiTpsKU/X4O1zU9WmKD5+e++mtbLOKFSgbSl6Lr vCZb3RbMnMXlVISSSBEqUdcRWaHheRy8bR883lK8ntdlRBArpnlRdgVkGF/VKxrP 7RR2XfmV/MVpAJ5kKSAd3FxIx0tljD3Otq7axY/r7+zV+JJc712gua5CA6IJY63g vRNlwIGS5np3BVnRUIg8Bi1Voek6wi4Rv9WOHMp9kjsd7r7EL4t4STLROfEpI1ra 3MqqhVj8X85GPq2wyBguC389rQ/REtgtG0DLyfFJ4ATEfjp+qjTt3qUpETGlRcEz uJXO1MjIxu2WRNV1qu9CDOivxDtEAhXJNPXf2Se0CZI4w4lvIwIWXqKh40SVyNiz bU5oieEqV4hClqXEl3mbw4V3rBYBGpMj4hPy4Oydw1qt9sgT4JR5vfLW6TNkLKCX CbjmwJQ5KR1y7NyvUHMJnvNpjFwrcyOKOs5LbXfFv+1wHG57oF2jcVyttqkK2Rul 0CRC9kznOuUJvsy/HcZJm4ptOyvhMqlNMrpaDY+Hk8rBop+XjcdWIg8upVRSBhah vsAyZHrBQg4oRWcPFALxOPlt+ReuwsNyDWKV33ZsVGFcuC0mkzswYPnVTYPt/V0B j/+2Tsecme0xyE9smAuJmQgVdU

* Holger Levsen <[email protected]> [250102 13:03]:

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

for experimental: yes, please!
for unstable: what Helmut said & does.

My thoughts too.

Cutoff date could be more aggressive, but I don't have a strong
opinion on it.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)