Re: "removed" Debian packages section&BTS tags
On Tue, 17 Sep 2002, Tomas Pospisek's Mailing Lists wrote:
> On Mon, 16 Sep 2002, Drew Scott Daniels wrote:
>
> > Having BTS entries for removed packages is useful, however perhaps
> > a flag is needed for them to reduce the work of Debian-qa and other bug
> > squashers. Currently bugs are closed [1] on removed packages. For this
> > reason I would like there to be a tag for "removed" packages, to be called
> > "removed" and I would like their bugs to remain open on the BTS.
>
> A separate flag is not strictly needed since one could just say:
>
> Maintainer: This package is currently unmaintained
>
> A related issue is that the original package still has Section:/Priority:
> in it, which AFAIK would have to be changed if moving the package into a
> different archive.
>
> So changing the maintainer field and/or the section would require
> re-uploading the package with those changed.
>
I was referring to a flag to be added to the BTS rather than having a
package's bugs simply closed. Some way to track down the last maintainer
would be useful.
Aren't currently (caught) unmaintained packages maintained by Debian-qa? I
haven't checked if any packages actually have them listed as the maintainer
though.
I would like "removed" to be an archive of almost dead packages and thus
messing with the maintainer field would not be necessary. Users of
packages in the "removed" section should be somehow informed that removed
packages are not maintained. Perhaps changing the maintainer field as you
suggest is the best solution, but I think it would have to be done by
Debian-qa or the maintainer of the "removed" archive.
> > The perceived negative aspects of such an archive are:
> [...]
> > *More work would be created for the qa group (but the archive is separate
> > and people who get from the "removed" archive should not expect the
> > support of the qa group).
>
> 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. I suppose a
procedure on how to properly remove a package would need to be created or
modified. I believe there must be some policy or at least a fairly strict
convention as there is a list of reasons as to why packages are removed.
> > *More bandwidth will be required (not a significant amount if they are
> > removed for what users believe is legitimate reasons. If significant
> > bandwidth is used for "removed" packages then perhaps the package
> > shouldn't have been removed?)
>
> Since aparently not many packages are getting dropped right now, the
> impact would probably be minimal.
>
I think it would be nice to see "bad" packages dropped and I think that
there are many in the archives. From what I've understood, getting
packages removed involves having someone look at each package and make a
decision, this is very time consuming and happens likely infrequently.
Maybe as "Davide Inglima - limaCAT <hadesnebula@libero.it>" suggests (in
his opencola itp thread) there needs to be more well defined criteria to
decide what packages are to be in Debian (&non-free) and what should be
removed. Maybe this would spawn yet another archive? Maybe I'm just
rambling, but the need for a "removed" archive is already here.
Drew Daniels
I'm still looking for work: http://home.cc.umanitoba.ca/~umdanie8
Reply to: