[Aptitude-devel] About closing bug reports -- was Bug#573626: aptitude: Terrible Interactive Search Performance

[Manuel A. Fernandez Montecelo]

2014-01-24 11:44 Axel Beckert:
>Hi,
>
>Manuel A. Fernandez Montecelo wrote:
>> Different maintainers have different styles, and the fact that neither
>> Axel nor I perceived this as a "bug" using aptitude for many years in
>> old machines and [for me, quite obscure] architectures, it means
>> simply that "it's not a bug" for us.
>
>Yeah, but that does not necessarily validate closing it. It though
>validates discussing _if_ we should closing it.
>
>I usually tend to keep them open in such cases, but I don't mind if
>everyone else agrees to close them.


I agree with this, and that's what I was trying to do: discussing if
it should be closed or not.

I simply expressed my opinion, but didn't actually close the bug
report.  That's the first step to try to gather a consensus on the
matter -- express one's opinion.  If we all agreed, or if nobody said
anything, maybe I would close it a few months down the line, but I
didn't try to close knowing that people have different opinions.

So I think that we are basically on the same page.


Now, I don't consider that bug one that should be fixed, increasing
the complexity (specially if it involves using background threads as
Daniel Burrows mentioned) for very little gain.  For example, a chunk
of code can always be written in assembly or using complex
optimisations, but it's not always (nor often) a good idea.  I see
this decision in the same way.  That's how all development is decided,
explicit or implicit cost/analysis benefit.

And about leaving bug reports open, I think that drawing attention to
problems with very little importance and that will most likely not be
fixed actually hurts the project.  We have plenty of those in the 600+
open reports, and I believe that we have better use for out scarce
free time.


Disagreeing with this is OK and all of the above is debatable;
mischaracterising my reply, patronising about the usefulness of bug
reports or the "me toos" of bugs.d.o is not:

- mischaracterising my reply several times in the same message by only
  replying to parts of it and assuming that I say more or less "just
  because it's not going to be fixed immediately, it should not be
  closed", without commenting on the real reasons.

  The reason to close it would not because it's simply complex or
  because it's not going to be addressed immediately (that was a
  polite way to put it, perhaps I'm becoming too "british"...), but
  because it's a bad idea to fix it.


- patronising is also not OK, I can easily reply with similar
  rhetoric: "Just because bugs are left open, they are not
  automatically or even eventually fixed.  That much should be clear
  by now".  Replying in such ways doesn't lead to useful discussions.


- and "me toos" are one reason why we have tons of merged reports and
  clearly indicate interest of the users (with patches indicating even
  greater interest).  No "me toos" does not imply that nobody else
  cares, but at least proves that not many people care enough to try
  to get it fixed.


The same issue of patronising and mischaracterisation apply in the
reply to bug #267162:

a) telling me off for not considering the work being done in
   "wip-cmdline" (untouched for 18 months) -- in which case, the fault
   --if at all-- is not having added comments on this bug report that
   this was being fixed in some way, or marked as +pending

b) that this issue was "confirmed by examination of the --verbose
   option", when this is would be a different bug altogether, or not
   at all... because "--verbose" is supposed to make other messages
   "get lost in the miles and miles of [other messages]", that's the
   whole point of being "verbose"

c) all I did was to say to the submitter that if he didn't agree,
   explain the problem in terms of current behaviour of the program,
   and desired behaviour.

   Bugs can be reopened, new information added, or new bugs submitted
   (so we don't drown in useless messages with obsolete behaviour
   before reaching the real issue).

   That's all what I did, evaluating the situaion, trying to confirm
   the problem and communicating my opinion in a respectful way to a
   bug submitter.  That's more respectful towards submitters than
   leaving the bug report unreplied for 9.5 years, I think.

   (Still, I think that's OK as well, because bug reports' purpose is
   to improve the project and not to not hurt submitter's feelings,
   and not everybody can spend lots of time dealing with bug reports
   while providing good software, which Daniel Burrows certainly did).


So, please, let's try to work together in a harmonoius way and respect
other people opinions even when we disagree.


Cheers.
--
Manuel