Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)
I'm going to disagree with two points here.
On Fri, 8 Jul 2005, Javier Fernández-Sanguino Peña wrote:
> - _No_ bugs in base packages (well, at least no old bugs). Base system
> should be upgraded to latest upstream (forward patches!) this includes
> PAM, modutils...
> * Base packages should be co-maintained and maintainers should be
> open to help (not always the case currently)
>
> - Review and fix or remove very old bugs:
> http://master.debian.org/~ajt/oldbugs.html
Well, I consider the idea that old bugs deserve more attention than new
bugs (or non-old bugs) completely flawed.
Bugs do not increase their severity by age. A wishlist bug which is
ten years old is still a wishlist bug. A normal bug which is ten years
old is still a normal bug. An important bug which is ten years old is
still an important bug (well, modulo the fact that the important
severity might not exist ten years ago :-).
While it would be a nice thing not have "old" bugs, it would be even
nicer not to have important bugs, for example, so I think we should
not chase "old" bugs because of them being old.
Sure, old bugs may be the symptom that the maintainer is MIA, that the
upstream maintainer is MIA, and similar things that we should of
course track as well, but it does not mean that an old bug is "worse"
in any way than a new bug (eveything else being the same).
> [...]
> - Remove _all_ out of date dummy packages! (see #308711 and other bugs!)
> Note: Almost done by ftp-masters, some pending and needs to be reviewed
> to remove woody->sarge which are not applicable to ->etch
IMHO, we should keep dummy packages around for at least two releases,
to support upgrades which skip one release. We can't argue that they
are difficult to maintain, or that they take a lot of space in the
archive. Sure, we can't test upgrades which skip one release as much
as normal upgrades, but if we know for sure that an upgrade will *not*
be smooth when there is a missing dummy package, we do not even have
to test the upgrade to know that it will fail, and there is no point
in gratuitously and knowingly breaking the upgrade.
Instead of a crusade against dummy packages (some of which are not old
enough so that removing them does any good), I would like to see a
crusade *for* dummy packages, so that a package which changes name
without a dummy package is considered a RC bug and we are forced to
fix it (see Bug#196390 for an example of bug which I think we should
not have released sarge without fixing it).
Reply to: