bugzilla triage madness :-/

[Andrew Farris]

Michael Schwendt wrote:
> On Tue, 08 Apr 2008 02:49:02 -0700, Andrew Farris wrote:
> 
>> Michael Schwendt wrote:
>>> On Tue, 08 Apr 2008 00:31:39 -0700, Andrew Farris wrote:
>>>
>>>> Michael Schwendt wrote:
>>>>> fail to see the guarantee that this time a report will be dealt with. All
>>>>> I see is that tickets were picked by age/by product and not by contents.
>>>> Waiting on the magic perl script that can do that, or the offer to have looked 
>>>> at the thousands of bugs manually instead of the script, now that would be 
>>>> productive and helpful.
>>> If you don't filter by package name, there will always be thousands
>>> of bugs.
>> I meant the thousands of bugs relevant to this discussion... filed as rawhide 
>> during an EOL release development cycle.  I'm suggesting that although in a 
>> perfect world a content parser would know how to deal with the bug (which you 
>> keep suggesting should have been used) its just not available.  A heuristic had 
>> to be applied, the triagers applied one in a best effort plan to correct the 
>> problem that was being created over a few years.  I'm leaving it to you to 
>> suggest an actual method of picking bug tickets by contents which is 
>> implementable without manual human interaction on every single one of them.
> 
> And you still don't want to understand. That's why you try to make a
> smart-ass post that fails to comment on the problem.

I understand very clearly what you're saying, but it seems you're as unwilling 
to consider the 'how' as you think I am misunderstanding your complaint about why.

> few packages with hundreds or thousands of bugs each. They make up the
> big pile of bugs that ask for automation -- the thousands of bugs you
> consider relevant.

Right, and as a 'whole' those are alot of bugs.  You seem to be saying that 
because the database CAN filter them by product that somehow reduces the total 
number of individual, old, stale, possibly irrelevant bugs stuck in the 
database.  Bugs that were filed against rawhide but have no clear way to 
determine what product they really were targeted for... other than a date of 
filing and the bugzilla number range (for instance the fact that most F9 rawhide 
bugs are > 41xxxx).

Sorting these by product only gives you smaller pages, it doesn't reduce the 
time needed to have a human check each one for relevance.  The original bug 
reporter, who could reproduce it at the time it was reported, is the ideal 
candidate to determine if the bug 'matters'.  If the bug cannot be reproduced in 
a product/release that currently matters, and is being supported, then the bug 
simply *does not matter* -- It has no purpose.

Just because a certain component only has 10 bugs vs. 1000 bugs of another does 
not mean that those few bugs are meaningful.  If half of them are filed against 
an EOL product, and the bugs cannot be reproduced in a current product, then the 
bugs have no purpose.  If a person has to sort through all those bugs how are 
they to determine whether they have a purpose?  Answer: ask the maintainer and 
the reporter to decide 1) has a purpose, 2) has no purpose.  Case 1) bug stays 
open, case 2) bug closes after 30 days.

> That doesn't mean you've got to touch all other
> packages, too, and auto-close their tickets in an automated way. You
> only do this if you don't care about bugs at all, if you are annoyed
> that users submit problem reports and expect you to evaluate them.

Wrong.  You do that when you 'no longer' care about that particular bug. 
Someone may have cared about the bug when it had a purpose; the maintainer may 
not have been able to deal with it then, perhaps the component was orphaned and 
noone was maintaining it for a little while.  Lots of reasons could exist for 
the bug becoming stale.  Why that happened no longer matters once the bug has no 
purpose.  Problem reporters who take that personally, and get depressed because 
a bug they reported is no longer relevant to anyone need to figure out why they 
are taking the time to report bugs... they *should* be doing it so that *if* a 
developer is able to correct it then it will be fixed.  They should not be 
reporting bugs on the assumption that it will always be relevant or that their 
bugs will always get fixed.

Software gets old and we leave it behind in favor of newer versions.  If the bug 
reporter, who should be the authority on what 'the bug' is, why it needs fixed, 
and how it effects them... cannot reproduce the bug, or does not care to, then 
it has no purpose.

Whether the current maintainer has thousands of bugs on one component, or there 
are 10 bugs on each of 100 components... the reporter should still be as 
involved in the bug as the developer.  If being asked to validate that a bug 
still has a purpose is too much effort, then the bug has no purpose.  Closing 
bugs which have no purpose should bother noone.

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB  5BD5 5F89 8E1B 8300 BF29