Mailinglist Archive: opensuse-factory (649 mails)

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

On 02/08/17 10:26, Carlos E. R. wrote:
On 2017-08-02 00:16, Per Jessen wrote:
Carlos E. R. wrote:

On 2017-08-01 23:42, Per Jessen wrote:
Carlos E. R. wrote:

On 2017-08-01 14:18, Per Jessen wrote:
Carlos E. R. wrote:

On 2017-08-01 13:34, Per Jessen wrote:
Carlos E. R. wrote:

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

I think the number of open reports alone prohibit that approach,
however nice it is.

So if the bug was sent to an incorrect destination, nobody will see
that and new bugs on that area will suffer the same fate in another
five years.

The reporter will also be notified.

But he will not have a clue what happened.

It will all be in the report?

No. We are talking here of bugs that get assigned to a person that is no
longer at the project, an email that doesn't exist, a mail list with no
subscribers. There is no way the reporter can find out what happened,
only an insider.

In the case of maintainers who are community members, many times
"insiders" wont even know what happened and in some cases it doesn't get
found until the package stops building in tumbleweed and doesn't get
fixed tracking and solving this is hard,, for example I maintain several
serial modem related packages that haven't changed for 5-10 years, this
doesn't mean there not maintained or doesn't work it just means they
don't need to change.

Over the last couple of years quiet some effort has gone into making
sure all the core packages have a bugowner listed in obs, hopefully as
part of that process the old bugs also got picked up but there is a
chance they didn't, which is potentially more likely when community
members have swapped maintainership.

So in short there are cases where especially older bugs may point to a
maintainer that's no longer active whereas if you create a new bug it
will go to the right person which is why I suggested in some cases the
cleanup will involve assigning the bug to the correct maintainer and
getting there opinion.


Simon Lees (Simotek)

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

< Previous Next >