On 01/08/17 21:54, Tomas Chvatal wrote:
Carlos E. R. píše v Út 01. 08. 2017 v 13:43 +0200:
Carlos E. R. wrote:
On 2017-08-01 12:18, Axel Braun wrote:
Am 31. Juli 2017 16:54:06 MESZ schrieb "Petr Hodac (Hody)"
: Hello
We were looking in Bugzilla queue and the number is horrible. We have loads of issues reported on products that are no longer supported or loads of bugs reported against Tumbleweed. Petr,
definitely a good idea!
Regarding unsupported releases, what is the plan here?
- close the bug as not supported anymore: less work but somewhat annoying and frustrating for the reporter(s)
If you do that, then why should I bother to report new bugs if nobody is going to care, even read it? :-/ Carlos, for the same reason we always have - in the vain hope a bug might be picked up and fixed. Having a report closed as "no longer under maintenance" is not just "somewhat frustrating", it is extremely frustrating, but what else do you propose we do? Pursuing a bug for a product that cannot be updated is pointless, but obviously the reporter is more than welcome to reopen if the problem persists in a maintained version. For starters, give some thought to the bug. Did somebody read it, or was it sent to a non existing maintainer? Then send to the current
On 2017-08-01 13:34, Per Jessen wrote: maintainer, and let him read it and decide.
If the bug was reported for an old application, ask the reporter to please try again on the new release and report back. Leave the bug as "needinfo", which shows interest.
Have a quick look at the bug, decide case per case if something can be done. Certainly do not mass-close.
And of course, a process needs to be created to detect bugs with no activity in long time. Detect when nobody reads a bug, or nobody acts on it.
Carlos, that is really nice to wish for all of this but did you see the amount of open bugs? It means that if we would do this for each and every one of them it would take one person aprox 235 days working 8 hours a day to get them to 0 expecting spending cca 30 mins per bug (so for the sprint it means 79 volunteers working 3 days 8 hours each day)...
Nobody can expect that.
With this sprint we will try to manage as many as possible, but if it proves like too much burden we will have to switch to automatic management like other projects.
Leaving bug on needinfo is nice, but does not solve the problem at all. Simply if your bug got closed and it is still present there is nothing easier than to reopen it...
For some products there is no activity since 2009. If nobody touched the bug for 8 years I get the feeling it is not that important to anyone (also quite few of them should be closed as upstream, because in the end we are supposed to track distribution issues, rather than problems in upstream software).
Cheers
Tom
Perhaps I misread what Richard wrote only recently which is that there is now a QualityAssurance piece of software which checks out the s/ware going into oS/SLE before it is actually released. The Q is: can this QA s/ware be adapted to check for the outstanding bugs? BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org