Mailinglist Archive: opensuse-factory (649 mails)

< Previous Next >
Re: [opensuse-factory] openSUSE BugHunting 2017


On 02/08/17 11:03, Basil Chupin wrote:
On 01/08/17 21:54, Tomas Chvatal wrote:
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)"
<phodac@xxxxxxx>:
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
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


The answer is Yes it could BUT, doing so requires more effort and
manpower then someone simply checking if the issue can be reproduced on
there own system. Its much better for general systems testing, ie here
is a list of things that users commonly do on a openSUSE system lets do
them and check they haven't broken. Or things like we have seen bug X or
similar 3 times in the last year, there's a reasonably high chance it
will happen again so lets add a test for it.

Over time i'm sure in an ideal world the QA team would like to see as
many cases as possible tested, but each test takes time to firstly write
and then maintain as programs change, themes change icons change, fonts
change etc.

--

Simon Lees (Simotek) http://simotek.net

Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

< Previous Next >