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

Re: Orphaned packages with very low popcon numbers



Bas Zoetekouw wrote:

> Well, as long as there are no RC bugs, and the packages are in testing,
> I really see no need to remove them.
Well, *if* they are in good shape and require absolutely *no* maintenance,
they should be kept, yes.

Blackbook may be in this situation.  (Checks: blackbook is dead upstream and
is missing the required copyright statement in debian/copyright, so no.) 
(However, it's only been orphaned since April, so it wouldn't be a
candidate.)  c2hs certainly isn't (it's uninstallable, and it's two
upstream releases out of date).  (However, it's only been orphaned since
May, so it also wouldn't be a candidate.)

Just to start in on the list.  I strongly suspect that most of these
packages, even the ones with "0 bugs", are going to turn out to require
maintenance.

If they require *any* maintenance, they are a waste of our time.  QA has
hundreds of packages to maintain, most of which have far, far more users. 
(Some have several thousand popcon installations.)

Requiring maintenance includes being out of date with respect to upstream,
any packaging bugs, "important" bugs, bugs regarding transitions, etc.  And
if there are no users, we can't actually expect most of these bugs to be
reported.

RC bugs are *far* too high a threshhold for removal of unmaintained
packages.

> Even if only a few people use the 
> package, why annoy them by removing it from Debian?

Keeping out-of-date, unmaintained packages in Debian is not a service, even
to the users of the package, who will generally be better served by
installing the upstream tarball directly (I'm sure there are exceptions for
packages with particularly awful upstream distribution formats, but those
fall under the "special cases" category).  In fact, it constitutes a trap
for the unwary.

Bas wrote later:
> Well, I could agree with removing packages if, in addition to the cited
> citeria:
> 
>  (i) there are RC or important bugs (or many normal bugs)
Or even a few normal bugs.  :-)

> or
> 
>  (iia) there are very few users (in the bottom 1% of popcon number or
>        so, not sure how much votes that would translate to, 20 sounds a
>        bit high IMO), and
Packages rank from 1 to 22692.  Bottom 1% would be rank 22467 and below.
This is in the "0 installations" category: the top rank for a
0-installations package is 22416.

The top rank for a 19-installations package (my cutoff choice) is 15339,
or approximately the bottom 32.5%.  I am only looking at stuff which is
*orphaned*, however.

>  (iib) there are replacement packages in the archive that deliver
>        similar functionality.

Pain in the neck to find out.

I would be OK with this if you added:

  (iii) package is significantly out of date with respect to upstream

> In other cases, IMO, it's a lot of work to check and remove the
> packages (both for the QA and the FTP teams), without any real gain for
> the project.

Well, IMO, the gain is as such.
(1) fewer packages for QA to maintain.  QA maintenance requires at least
identifying when a package is severely out of date with respect to
upstream, fixing any RC bugs which may crop up, etc.  It doesn't get done,
but it needs to.  The fewer package which are lying around, the more likely 
that this will actually get done for the packages which need it.
(2) fewer junk packages to mislead unwary users.  It is really perverse to
offer blackbook, which is dead upstream and unmaintained in Debian, to
Debian's users.

IMNSHO, packages which have no maintainer and look unlikely to acquire one
should be removed from Debian by *default*, and kept only if there's a good
reason to keep them.  A significant number of users is usually a good
reason, hence the filter for packages with very few (if any) users.

-- 
Nathanael Nerode  <neroden@fastmail.fm>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...



Reply to: