[Aptitude-devel] Bug#814996: Bug#814996: aptitude: purge does not "stick" the first time

[Axel Beckert]

Hi,

Manuel A. Fernandez Montecelo wrote:
> Control: reopen -1
> Control: fixed -1 aptitude/0.7.7-1

Doing this is not really a good thing IMHO. That bug is fixed in
unstable and has a severity level (normal) which usually doesn't get
fixed in stable after the release anymore.

> >What bugs me is closing a bug that is neither fixed (in stable) nor
> >(going to get) documented anywhere. It's just going to get archived

That's expected. Bugs fixed in unstable and having a severity below
"important" are archived automatically. Only bugs of the severity
"important" or higher are not automatically closed, if they also apply
to a supported release of Debian as far as I remember.

> >and then it won't even show up in reportbug anymore.

reportbug is not authorative. The BTS is. And the BTS allows you to
also search for archived bug reports.

If you dislike that reportbug doesn't show archived bug reports which
still apply to the release you're using, then please file a bug report
against report bug, not against packages of maintainers which use the
BTS as intented.

> >This is not the first bug I've come across in the last few weeks that
> >turned out to be a possible dupe of a months-old archived report, with
> >or without any indication that it still affected the current stable

Yes, as explained above, that's expected. Use the BTS and search also
for archived bug reports if you look for low-severity bug reports
which are fixed in unstable, but still may affect stable or oldstable.

> Anyway... leaving the above aside...  If we close the bug with fixed
> version 0.7.7-1 for example, I think that it will appear in reportbug
> (when reporting from a system with < 0.7.7-1 installed),

Does reportbug check which bug is fixed with which version? I doubt
it. But then again, I use the BTS, not reportbug to query bug reports.

> and it will also appear in some views of the BTS (when selecting
> "dist=stable", for example)

I think you will still have to explicitly query archived bugs if you
want to see low-severity bugs already fixed in unstable.

> -- but I think that the view in BTS is to show unstable by
> default.

Yes, it does if you use the shortcuts, e.g.
http://bugs.debian.org/aptitude it redirects to
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=aptitude;dist=unstable

> >In my ideal world this bug would be marked "wontfix" for all versions
> >of aptitude known to be affected (but otherwise kept from being
> >archived as long as an affected version is supported) and "fixed in"
> >for the earliest version known not to be. I'd thought the BTS could do
> >this, but perhaps not. What do I know, I'm just a user. Also a
> >/usr/share/doc/*/ERRATA.Debian containing short summaries of all known
> >issues that won't be fixed in the current branch would be nice. The
> >bug numbers and subjects would do, as long as the latter are
> >descriptive.
> 
> One of the problems with this is that, most of the time, I don't even
> have the means to test if the bug was present in stable, simply because
> I don't have other machines around.  Only when I have access to the
> computer of other friends/family with stable installed and root access I
> can test some of these things.  And some of them require specific
> changes (configuration, a specific repository, a "state bundle" or the
> right architecture, etc) that are not trivial to reproduce.

Manuel: I usually can also test things on stable and oldstable. (No
more live running squeeze anymore since recently, though.)
Additionally I can test no more supported releases via Xen virtual
machines, if necessary. Bootstrapping such a VM usually 5-10 minutes.

I though don't think it's worth to dig that deep in nearly all cases.

>From now on, I'd only test wheezy and jessie and if I can't reproduce
something on Wheezy, I'd mark it as fixed with the version initially
in Wheezy (i.e. not the current version which might be from a
stable-update). Otherwise with the version in Jessie/Testing/Unstable,
depending on where I can't reproduce it anymore.

> Also, for some of the bugs that I tried to reproduce in the 0.7.x
> series, I cannot go further back than 0.7.5-1, because that's the moment
> when apt-1.1 was released, and installing older versions of apt for
> every bug that I want to reproduce is not practical and can break my
> system.

Indeed. That's even difficult with a dedicated VM for the test and
IMHO usually not worth it. (Installing the previous stable release and
then dist-upgrading to the date the bug was reported via
snapshot.debian.org sources.list entries is possible, but very
tedious.) Compiling an older aptitude version on a current unstable
may be quicker, but less accurate.

> Finally, as more personal note...  Above all, the whole thing of bug
> triaging for a project of aptitude (and other parts of Debian) is very
> time consuming, boring and energy-draining, even in the best of the
> scenarios.  Going for a much more accurate triaging will surely impact
> other areas of development, and our (or at least, my) inclination to
> dedicate time to aptitude, so I am not sure if it's a good trade-off.

I'm very happy about how it went the last half year since Debconf.
Manuel did an impressive amount of work and I think we should not put
much more time into digging in outdated code.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE