We have many orphaned packages in Debian. Those are packages that no longer have a maintainer willing to care for them. They are a problem for several reasons. Often, there have better alternatives (that’s often why the maintainer gave up maintenance), but users keep installing them because they show up in apt-cache search. Or, they might be broken, without anybody noticing because they only have a few users. Also, developers need to take them into account. They might slow down transitions, have RC bugs that need fixing, etc.
So, there are good reasons to remove some of the orphaned packages from the Debian archive. Not all of them. But those that have been orphaned for a long time without anybody stepping up to take over the maintenance, have very few users according to popcon, etc. Removing some of them also makes it easier to expose the ones that should really find an adopter.
Also, that removal is not final. The good reason to do this now is that we are at the beginning of a release cycle, and that it will be easy to reintroduce packages that are really needed during the next two years. Also, packages (both source and binaries) are still available on snapshot.debian.org, so users can still install them from there, and re-uploading them to Debian is very easy if someone wants to adopt them.
So, how do I proceed? I use bapase, and go through specific sets of packages (using a custom version of bapase to restrict the list to those packages). For example, orphaned packages that have a popcon lower than 50, have been orphaned for more than 500 days, and whose orphaning bugs have not been modified in the last 100 days. Then, I read the bug log, and decide if there’s a reason to keep the package. If there’s not, I request the removal.
As of today, there are 471 orphaned packages in Debian. The goal is not to get down to zero, but it’s certainly possible to get down to 200 or 250.
How can you help? Start from the list, and find some easy targets. You can take a look at bug #483252 if you want to re-use my template. Also, one thing that is currently missing in the process is that orphaned packages that have reverse-dependencies should not be removed without removing their dependencies (if appropriate). An easy and efficient way to know if a given package has reverse (build-)?dependencies would be great, so I could integrate this info into bapase and exclude those packages from the list, or mark them somehow.
Albeit I find myself in a similar situation when removing packages from testing wrt popcon count, 50 does sound a tad high. After all Debian’s goal is to be universal, so bug-free niche packages could be kept around as long as it doesn’t cost us anything? For <10-15 I might agree somewhat, though.
How do you know it’s bug free if it’s an unmaintained niche package? Most users don’t report bugs they found.
I think that the consensus on the topic is that Debian doesn’t aim at being universal: we should not try to package each and every existing piece of free software, but instead, at packaging the software that users need. And if nobody worries about an orphaned package for more than a year, I think that it makes sense to consider that it’s not that needed.
The alternative is to acknowledge that we cannot package everything with the same quality standard. But I don’t think that we want to go in that direction.
Well, if you’re in that [10, 50] range, there are some users that might need it. I guess we should agree on a sane barrier, I’m just not sure if 50 is it. (Apart from the fact that popcon still isn’t default on?)
I’m not saying we should package everything, but everything that’s useful to some. How many packages are <50 in total? We're just arbitrarily putting the bar higher for orphaned packages than for "maintained" ones which might not get any care neither. ;-)
We shouldn't end up at the point where the popularity contest is really a contest to stay in. :-P
How do you define “useful”? ;)
It seems to me that if it’s not useful enough for someone to care to maintain it, then it’s probably not worth keeping.
Well, you need a developer to care enough about it. Someone alone isn’t enough, as that someone would need to find a sponsor for the very least.
I think it’s a tad dangerous to infer from bug freeness that nobody cared enough to report a bug. If there’s a significant bug and nobody cares enough, meh, let’s get rid of it.
This is a fundamental misuse of popcon data. Popcon does not tell us how many people use a package. It can only tell us if package A has more users than package B, and roughly what factor. That is enough information to arbitrarily decide whether package A or package B should go on a CD; it can provide a hint as to whether we should focus effort of package A instead of package B, but it cannot tell us that package A has less than 50 users.
You may be throwing out packages with 50, or 500, or 5000 users. You don’t know what the general popcon multiplier is, and it can be different for different classes of packages too.
If popcon data is going to be misused this way, perhaps we should rethink whether users are encouraged to use it?
Huh? I don’t know what gave you that impression, but I never wrote that a popcon of 50 meant that a package had only 50 users. However, generally speaking, it can be assumed that if popcon(A) < popcon(B), then users(A) < users(B). So A should probably be considered for removal before B.