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

Fri Mar 4 01:46:23 UTC 2016

Control: reopen -1
Control: fixed -1 aptitude/0.7.7-1

2016-03-01 19:01 Christian Pernegger:
>2016-03-01 18:53 GMT+01:00 Manuel A. Fernandez Montecelo
><manuel.montezelo at gmail.com>:
>> Perhaps.  But in any case, even if the underlying problem was actually a
>> different one, if several people cannot reproduce it in 0.7.x and there
>> are reasonably indications that it was fixed, it means that it's
>> probably fixed.
>
>Agreed.
>
>> And more in general, if we cannot reproduce it there's not much that we
>> can do about it.
>
>Also agreed, but people can (in the jessie version).
>
>> Sorry, but we don't have the resources to backport versions to Jessie,
>
>That's perfectly understandable.
>
>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
>and then it won't even show up in reportbug anymore.
>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
>...

Fair enough.

<verbose mode on...>

In general I dislike closing bugs with "fixed" versions when I don't
know which version actually fixed it, or if it's not a bug fixed with
specific changes of aptitude that I can point to.  Among other things,
this can be misleading when triaging other bugs and trying to find
conditions that triggered it in the past, etc.  Seeing in the header
that it was "fixed" in some version and trying to find in the changelog
what changed triggered that, only to find that it didn't actually happen
at that point, is a bit frustrating, and it happened to me with aptitude
a few times already.  So as a developer, marking with "fixed" versions
when it's not accurate is actually harmful.

Another problem is that, as most software projects, it relies on other
libs (specially libapt in this case), so many of the bugs are fixed or
occasionally arise suddenly without anything changing in aptitude, but
in the supporting libraries.  When a few months or years pass, it's
difficult to know if it was fixed in the version that went to the last
stable or not.  And most of the bugs still currently open were
unatteneded for several years.

In this bug in question that we're discussing, I pointed to a possible
change that fixed it, you think that it was working fine by the time
that the other bug fixed was reported... so what then?  There are still
users of (jessie-1)-LTS...

Sometimes it's even quite difficult to know if they are present or not
/today/, but a 10 year old bug that happened once when the user was
running aptitude through PuTTy and ssh, in which the terminal was
scrambled after some keystroke, but there are no people "me-too'ing" and
the reporter doesn't reply or the address is not valid, it's not so
clear cut whether we should close it with a "fixed" version or not.  You
might think that this is an extreme example, but among the thousands of
bugs reported a good few hundred are like these; and keeping hundreds of
bugs open it's not very useful for the development of aptitude and
getting things fixed -- the trees and the forest and all that.

So, to recap, you are right about the good practice in general and for
the benefit of the users.  But consider this... aptitude had ~650 bugs
by last summer and 1000+ 3 or 4 years ago, even now has 340.  Maybe you
pay attention to duplicates, but at least among reporters of aptitude I
can assure you that many people don't -- and with so many open bug
reports I don't blame them.  The page takes 15 seconds to load (much
more a few months ago) and reportbug is impractical to search through
them in most cases.  Even if one wanted to pay attention, is very hit or
miss, because sometimes there are bugs older than 10 years which are
still valid, while there are others which are valid only for a specific
point in time, thus tagged as confirmed, when a change was made to
apt/infrastructure/archives that caused a spike... but that 2 months
later is not present anymore, and 5 years later is still opened and
"confirmed".

</>

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), and it will
also appear in some views of the BTS (when selecting "dist=stable", for
example) -- but I think that the view in BTS is to show unstable by
default.

Copying Axel, which has more experience with all these things.

>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.

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.  And I already fixed a lot of bugs between the version in
aptitude in stable and 0.7.5-1, so it's difficult to pinpoint the exact
point in some cases.

Compiling a list of issues in /usr/share/doc/*/ERRATA.Debian wouldn't
work very well, first because we would need to make a release if only to
update that file, and second because --once again-- we (or, at least I)
lack the time and energy to do even more bookkeeping and boring work.

So a problem of resources again.

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.

Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>