Re: [PROPOSAL] Archive audit, cruft removal, unmaintained packages

[Richard Braakman <dark@xs4all.nl>]

Ben Collins wrote:
> It seems to be to be less work. If some one else takes the time to atleast
> come up with a list of cruft that needs to be removed and takes the time
> to research each one and determine the course in which to remove it, then
> all you have to do is "rm -f cruft_file" (and update the archive database
> of course).

You are right, this kind of work can be helpful.

> > It might be good to put a note in the Shared Library policy that makes
> > the library maintainer responsible for the transition to a new major
> > library version.  Simply uploading a new version with changed package
> > names is the usual course, and it puts the problem in our lap.
> 
> That's a good start, but it's nothing more than rhetoric if we don't have
> a clear policy on the repercussions for not following this (ie.
> "irresponsibility in regards to library upgrades that break or seriously
> hurt the distribution will result in the library package being removed
> from your maintainership", yes it's harsh).

Urgh, that's no way to talk to maintainers.  I have something much
simpler in mind:

Library changes, as well as other kinds of package renaming, must have
a description of the transition strategy (or a reference to such a
description) in their changelog.  In some cases, this can be as simple
as "Nothing depends on the old package so please remove it".  In others,
it can be very complex indeed (such as the libc5 -> libc6 transition).

If there is no transition strategy, the archive managers will reject the
package.  [This is the major change; the status quo is that we try to
guess at a good strategy, or just ignore the problem].

This makes the transition clearly the package maintainer's responsibility.
It is unfortunate that rejecting a package is the only way we can
communicate about the package.  Maybe we should design some kind of 
holding area.  (Incoming/REJECT does hold a package for two weeks, though.)

This information should probably go into the Developer's Reference.

> > This could be useful.  Some proposals have been floating around for
> > nonintrusive maintainer pings (i.e. using such information as can be
> > collected automatically), and they will be a benefit.
> 
> They have been floating around for more than a little while, and people
> seem to regard it as unfair. I think these people need to get a grip and
> decide just how important Debian is as a whole, ie. some order needs to be
> instilled before our acceptible "chaos level" get's too unmanageable.

I don't think so.  I've seen maintainer pings discussed before, but
the idea of intelligent maintainer pings wasn't discussed until this
year, to my knowledge.  I've seen only positive reactions.  Someone
should write the scripts for it and see what happens.

> Agreed. Most likely record keeping will have to start from the beggining
> of the fork. Then at freeze, schedule known obsolete packages for removal
> and determine how to resolve any issues in removing them. At deep freeze,
> the packages go.

I don't think we should wait till freeze time, it will be hectic
enough as it is.  Removing a package at freeze time is appropriate if
it should be left in "unstable" but not in "frozen".  A package that
is to be removed entirely should be removed as soon as the decision is
made.

Richard Braakman