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@xxxxxxxxx> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
