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

Bug#693351: RM: kismet/2008-05-R1-4.3



On Wed, 12 Dec 2012 04:18:18 +0100
Nick Andrik <nick.andrik@gmail.com> wrote:

> First of all I also CC the DD that follows my work on packaging the
> new version, since I am not an expert on all debian procedures yet.
> 
> About removing kismet or not, I don't know what are the arguments for
> and against.
> I need to know the exact implications in order to give an informed answer.
> 
> If we include it, what is the disadvantage?

The Debian package is not available for new installations. It doesn't
show up in apt-cache searches.

The advantage is that the poor quality of the package no longer
reflects badly on Debian - as it does currently.

> It is not installed by default anyway, and I don't expect anyone to be
> using the version shipped with debian.

So remove it already.

> The upstream also provides a .deb which works quite well and my
> estimation is that everybody uses that one.
> This means, I don't think anyone will file any new bugs, functionality wise.

It also means that there's no loss by removing it.

> If we remove the package, do we also "lose" all the bugs filed against it?

No. Bugs which only apply to the version(s) in testing or unstable will
be closed by the removal, bugs found in versions in oldstable and
stable will remain open. (oldstable until the next stable freeze
starts). Packages are not removed from stable or oldstable.

Bugs are never deleted (except spam ones) - the bug will be closed and
archived but it can always be unarchived and reopened (in that order).

> Some of them are still valid issues which will be addressed in the new package.

If the package is reintroduced, the old bugs will be available to be
re-opened and tested with the new version. The bug numbers remain the
same and because there is a version of the package in stable, the index
page for the package will remain too. It is trivial to switch that page
to looking at archived bugs instead of the default unarchived.

> For the functionality bugs, I plan to give a notice to try the new
> package once it is released and close the ones I get no answer after
> some period (e.g. 1-2 months)

Does that mean you will be adopting kismet as maintainer after the
Wheezy release? 

> Also, I think the procedures for uploading new/heavily updated
> packages is different.

During a release freeze, yes - major changes and new packages should
be uploaded to experimental only. Outside the freeze, major changes and
new packages can go to either experimental or unstable.

> One should pass through the new queue, the
> other through experimental.

No. A package which has been removed will always go back through NEW if
it is reintroduced. After going through the NEW queue, it can go into
either experimental or unstable.

If the package has not been removed, a new upload won't go through NEW
whether it's aimed at experimental or unstable.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpO_EC6RyXh9.pgp
Description: PGP signature


Reply to: