Nicolas Mailhot wrote:
Le vendredi 04 avril 2008 à 05:41 -0700, Andrew Farris a écrit :
But what could be gained from trying to solve bugs in software that is long
modified to be unrecognizable from the state it was in then...
Packaging problems persist even if the underlying software was updated
many times.
Maybe, but not necessarily. Lots of packaging issues get solved without a bug
and it may have just been overlooked when it was solved. How is anyone going
to know this without spending an inordinate amount of time deciding if the old
bug still exists? Who is better equipped to do that than the original reporter?
If they don't have time, fine... let the bug get closed.
Next time do not flood reporters flood component owners (with a 'can we
close this yes/no ?' if no answer do not close is assumed) since
component owners are the ones asking to push stuff under the carpet and
should at least perform some activity to get their wish.
It is the component owners and packagers that already are flooded with too many
old bugs to get through, now you suggest they get requests for individual
attention on each? That sounds like a great plan for Congress, not for open source.
Anyway the damage is done, decent reporters will forgive the bug zapping
project this time but you've just expended your error budget and will
need to win a lot of credibility back before another mistake is
forgiven.
Either you as a bug reporter value your time and effort spent helping this
project or you don't; quite honestly this is nonsense, if you think you're
making a difference in the product you'll keep doing what is needed, if not
you'll stop. Getting a few bugs closed is not a viable argument for either choice.
Its regrettable that some bugs got left
behind when they did, but a bug filed against 'rawhide' in 2006 is obviously
obselete and you know this.
A bug filled against rawhide in 2000 which had a comment in february
2008 is obviously not obsolete. What counts is activity not date of
creation
Yes.. but the system of designating bugs stale was not in place in Feb. Its a
new change being made in the workflow; you cannot assume with a script that the
change in feb meant something useful (i.e. keep this open). The script has to
decide what to do based on something deterministic.
This isn't rocket science, and if bug reporters (of which I am one, don't get
angry at me because its misplaced) were paying attention they would know that
bugs will be placed in NEEDINFO and closed if they stay that way. All a
reporter, or commenter on the bug, needs to do is get the bug out of NEEDINFO
state by supplying the needed info. If that is nothing more than a comment 'its
still an issue in f8' then thats all that should be done.
A comment made on a bug in feb, which is an old bug, could have been something
like 'hey why is this still open?' and the script would have to understand
english (and some people's partial english and internet slang) in order to
guess... I'm hoping you're willing to toss that 'patch' to the bug triage team
in the next day or two.
--
Andrew Farris <lordmorgul@xxxxxxxxx> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29
revoked key 0xC99B1DF3 no longer used
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
