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