On 2024-08-15 5 h 55 p.m., Scott Kitterman wrote:
As a first cut, I would exclude archived repositories for removed packages
(e.g. ptable).
Thanks, I did see this after the fact (although there's very few
repositories that are archived).
If the team as a whole is keeping a package up to date, I think we should be
happy that the package is maintained and not expend effort to make it harder
for people to do that.
I think that makes sense for a subset of packages, but in general I feel
that puts a lot of burden on a few people, especially during transitions.
If people do find they tend to team upload the same packages again and
again and want to take care of them, they should adopt them and add
their names to the Uploaders list.
If we can get a list of packages that should be orphaned, it might also
motivate people to adopt them and take better care of them.
I'm really not sure how you are going to sort through this. Another example is
appdirs. Yes, I didn't upload it the last few times someone touched it, but
it's not in need of an upload now. What it really needs is to be removed, but
there's a key package that depends on it. I don't think it's stale at all in
any meaningful sense, but I don't know how you would know that without spending
more time on the package than it's worth.
I think it would be more useful to work on finding team packages that aren't
maintained at all and have issues. Those should either be fixed or removed.
Crossing different "smells" like no human uploaders outside of "stale
uploaders", no recent releases, new upstream versions not packaged, etc.
would probably yield a more tame list of packages one could have a look at.
I agree going through the current list as-is by hand is not worth it :P
In the end, I'm not 100% sure what I'll do with all of this yet, but
suggestions are welcomed.
I do have some code to run a bunch of tests on all of our repositories
though and that was also a goal of mine.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
