Mailinglist Archive: opensuse-factory (649 mails)

< Previous Next >
Re: [opensuse-factory] openSUSE BugHunting 2017
Carlos E. R. píše v Út 01. 08. 2017 v 13:43 +0200:
On 2017-08-01 13:34, Per Jessen wrote:
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)"

We were looking in Bugzilla queue and the number is horrible.
have loads of issues reported on products that are no longer
supported or loads of bugs reported against Tumbleweed.


definitely a good idea!

Regarding unsupported releases, what is the plan here?

- close the bug as not supported anymore: less work but
annoying and frustrating for the reporter(s)

If you do that, then why should I bother to report new bugs if
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
frustrating, but what else do you propose we do?
Pursuing a bug for a product that cannot be updated is pointless,
obviously the reporter is more than welcome to reopen if the
persists in a maintained version.

For starters, give some thought to the bug. Did somebody read it, or
it sent to a non existing maintainer? Then send to the current
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
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.

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).


< Previous Next >
Follow Ups