[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Work-needing packages report for Sep 6, 2002

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: pgpMQ8hZA8M9R.pgp
Description: PGP signature

Reply to: