On Wed, Sep 11, 2002 at 06:56:09PM +0200, Tomas Pospisek's Mailing Lists wrote: >> Yep. We have 10000 other packages that (we hope) people are using, and >> we shouldn't waste time on things nobody wants to take responsibility >> for. > On the other side nobody is forcing anybody to care. That's up to the > individual. I do respect the work QA is doing but it's a free choice to > pick up that responsibility. > If one doesn't want to care about packages, then s/he just shouldn't. > Forcing people to do without a package because one took the burden to > care about it freely but is not willing to carry that burden is not > correct. It's a problem that respective person has to solve for > him/herself, not for the other people. Nobody is forcing you to do without the package; indeed, no one is forcing you to install only packaged software on your system. OTOH, some of us do have the expectation that, if we install packaged software from the Debian archive, the packaging and integration will be of a certain quality (even if the software itself is not :). If I go looking for a package for a program, and I don't find it in the archive, I know that I'll need to allocate some resources for getting the program properly integrated into my system; and I can make a conscious decision whether to ITP the software, install from source, or find a packaged alternative. But if I install the package, and it's orphaned/unmaintained, I may be blindsided by new or previously-undiscovered bugs months down the line. Then I'm the unlucky guy to find out no one's used the software in two years, and it's no longer compatible with modern kernels/hardware/protocols. Thing is, if a package has no maintainer, we have NO guarantee that ANYONE is using the package; it may be that the only testing it ever gets is to make sure it's installable. The highest-quality packages are not the ones with the shortest bug lists, they're the ones that are proactively QCed. The Debian QA group doesn't have time for that kind of extensive per-package testing, and I sincerely doubt that it ever will. We need to be realistic about what we can expect from an understaffed QA group (kudos to them) whose main goal is to do BTS triage, and who may not have the skills or hardware necessary to do more. So if a package is orphaned for a long period of time, it should automatically become a *candidate* for removal: we should automatically begin the process of questioning whether keeping the package around still serves our users' best interest. Of course there should be opportunity for objections (and especially adoptions), but we shouldn't wait until someone *notices* a package is without a maintainer, because by the time someone notices the package has been orphaned for a long time, it's already received more attention than some packages more in need of removal from the archive. :) > And, btw. and IMHO: there is a lot of software that is "maintained" but > of lesser quality than non-maintained software. Different issue. One flaw does not excuse another. >> I think that it is not anywhere near as important to be able to say >> "anything you want you can apt-get install" as to be able to say >> "anything you want you can apt-get install and it'll be good". > The important thing here being that you __know__ what you get. If you know > that you're installing software that is buggy, than that's your choice. > And again: unmaintained != buggy. Would you care to provide evidence that there is NOT a high correlation between maintainer inactivity and package bugginess? This assertion seems quite counterintuitive to me, and all of my own anecdotal evidence supports the contrary. >> Of course there are exceptions on both sides. That's why removals should >> be requested and processed by humans, and why they're requested by >> filing bugs so that there's room for people to object. > I completely agree with this paragraph. As do I, but I think removal requests should be filed more often than they are now. Steve Langasek postmodern programmer
Attachment:
pgpNA6fdlef2m.pgp
Description: PGP signature