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

Re: "removed" Debian packages section&BTS tags



On Tue, 17 Sep 2002, Colin Watson wrote:
> On Tue, Sep 17, 2002 at 11:40:45AM -0500, Drew Scott Daniels wrote:
> > > I'm not certain. Currently everything is QA unless someone really drops a
> > > package from Debian alltogether.
> > >
> > > This way QA could easily and quickly decide without causing much pain to
> > > anybody whether they think it's necessary and useful to still maintain a
> > > package. But I think QA's opinion'd about this is relevant.
> >
> > Yes, qa needs to be consulted regarding this proposal. I don't believe
> > that it *should* create more work for qa, but it may.
>
> It will obviously create more work for QA, which is why I think it's a
> bad idea. We can't just distribute packages and then say "oh, but we
> don't support those in any way at all"; that would be irresponsible.
> Therefore, QA (or some other group made up from basically the same
> people) will end up doing it. When somebody from the QA group asks for a
> package to be removed, it is typically because they think it has too
> many problems for even QA to maintain it any more, i.e. it should be
> junked altogether.
>
A strong disclaimer wouldn't be enough? Well, perhaps not. It's not just
QA that decides that packages should be removed. I worry that some
packages get dropped due to lack of developer interest and not any other
reason (users may still want a package).

> We're here to distribute free software for the benefit of our users and
> the community. As such, we should not distribute stuff we aren't
> prepared to support *at all*, especially not if we're letting bugs keep
> on piling up about it. It's just wrong to invite bugs to accumulate and
> be ignored. The packages in the proposed removed archive would have to
> have a group assigned to at least nominally respond to problems. So, in
> other words, either the work assigned to the QA group goes upward
> without bound (unless the world ends and people start adopting packages
> more quickly than they're orphaned, of course), or we accept that from
> time to time it's appropriate to remove packages completely.
>
Perhaps another group should do this then?

> To be constructive, I think a much better idea would be to put together
> an interface (that could go on the debian.org web pages somewhere) that
> would let you search for removed package names, give you a reason why
> the package was removed, and possibly a pointer to the appropriate part
> of snapshot.debian.net. Properly publicized, this would fulfil the need
> to let users know what's happened to the package, without the overhead
> of a separate archive section.
>
I agree that this would also accomplish many of the goals in my proposal
although I worry about snapshot dropping packages that are older. I am
also unsure as to whether source, diffs and dsc's are kept on snapshot.

I would indeed prefer your solution. But to your solution, I would prefer
something more tightly integrated into apt. Perhaps removed packages get
descriptions with appropriate information or a link to appropriate
information? Perhaps dselect and alike programs could have features to
make it easier to find out relevant information. Perhaps a web interface
first with wishlist bugs against appropriate front ends.

> Remember that there are also packages whose maintainer requests their
> removal, because they're either no longer necessary, illegal to
> distribute, or whatever. From the user's point of view the removal is
> just the same as the removal of an orphaned package with whatever
> problems it might have, yet I don't think Debian is here to burn disk
> space forever on packages whose maintainer has said we don't need them
> any more. Much better would be something that tells users in all these
> cases "we've removed this package on ... because ..., and some possible
> replacements are ...".
>
The only problem I have is that sometimes the maintainer or QA's decision
might not be the best solution for users. As you say package removal can
be based on a maintainer who has said we don't need the package anymore.

A better link to information on why a package has been removed and better
recovery should someone decide it was a wrong decision to remove a package
is what I'm seeking. This provides both accountability and recovery if
desirable.

It'd be nice if the appropriate parts of snapshot could be mirrored. A
"removed" section would help with this.

     Drew Daniels
I'm looking for work. My resume is at:
http://home.cc.umanitoba.ca/~umdanie8



Reply to: