Axel Braun píše v Út 01. 08. 2017 v 12:18 +0200:

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)

- review each bug and request for verification in newer releases: more work but shows committment

For now we considered at least short checking if it is relevant issue even Today. If at the end of the sprint there will be still many open bugs on dead products it might be revisited and we could switch to Fedora approach (closing all bugs in batch). Cheers Tom

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? :-/ -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-08-01 13:18, Werner Flamme wrote:

Carlos E. R. [01.08.2017 13:15]:

...

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, you did read that Axel wrote about unsupported releases, didn't you?

Yes, my reply was sent on his post. :-?

And what would be good for to open bugs for unsupported releases now?

You mean open a new bug for an unsupported release? Why would anybody do that? :-? I don't understand your reply. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-08-01 14:03, Werner Flamme wrote:

Carlos E. R. [01.08.2017 13:46]:

...

On 2017-08-01 13:18, Werner Flamme wrote:

...

Carlos E. R. [01.08.2017 13:15]:

...

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, you did read that Axel wrote about unsupported releases, didn't you?

Yes, my reply was sent on his post. :-?

...

And what would be good for to open bugs for unsupported releases now?

You mean open a new bug for an unsupported release? Why would anybody do that? :-?

I don't understand your reply.

Exactly that is happening to me with your post.

I understood that Axel proposed to simply close bugs for unsupported releases (as one of two possible methods), you didn't quote the other.

I understood your response so that you do not like that because you do not see why anybody would report a new bug then.

I do not see any connection between opening a bug to a supported release and closing bugs to unsupported ones. So I thought you were concerned about opening bugs for discontinued releases. Sorry for that misunderstanding.

Yes, I think you are getting the idea now :-) My meaning is that, if I open some bugs which I take time to investigate and after some years they are closed without anything done with them, next time I will not bother to report bugs, because reporting is useless. It only applies to one of Axel proposals, not the other one. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 02/08/17 10:51, Basil Chupin wrote:

On 02/08/17 05:09, Carlos E. R. wrote:

...

On 2017-08-01 14:03, Werner Flamme wrote:

...

Carlos E. R. [01.08.2017 13:46]:

...

On 2017-08-01 13:18, Werner Flamme wrote:

...

Carlos E. R. [01.08.2017 13:15]:

...

On 2017-08-01 12:18, Axel Braun wrote: >

I understood that Axel proposed to simply close bugs for unsupported releases (as one of two possible methods), you didn't quote the other.

I understood your response so that you do not like that because you do not see why anybody would report a new bug then.

I do not see any connection between opening a bug to a supported release and closing bugs to unsupported ones. So I thought you were concerned about opening bugs for discontinued releases. Sorry for that misunderstanding. Yes, I think you are getting the idea now :-)

My meaning is that, if I open some bugs which I take time to investigate and after some years they are closed without anything done with them, next time I will not bother to report bugs, because reporting is useless.

It only applies to one of Axel proposals, not the other one.

I think what you arguing about is more relevant re another option which Petr put forward, namely: "Wontfix/Feature: issue is a feature request/or something that should not be fixed by us".

If it isn't going to be "fixed by us" then who should "fix" the problem reported by a user?

If it is a "feature" requested by a user then to whom should the user have reported the feature in order for it to be considered for implementation?

In both case this is where your comment about "why bother to report anything if it is going to dismissed out-of-hand" comes in.

BC

Hopefully there isn't too many such reports, generally good maintainers will have sent the people to the correct place for feature requests or if they were felling extra nice opened feature requests on there behalf in the right place. New features don't belong in our bugtracker in almost all cases anyway. -- 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

On 02/08/17 12:22, Basil Chupin wrote:

On 02/08/17 11:39, Simon Lees wrote:

...

On 02/08/17 10:51, Basil Chupin wrote:

...

On 02/08/17 05:09, Carlos E. R. wrote: I think what you arguing about is more relevant re another option which Petr put forward, namely: "Wontfix/Feature: issue is a feature request/or something that should not be fixed by us".

If it isn't going to be "fixed by us" then who should "fix" the problem reported by a user?

If it is a "feature" requested by a user then to whom should the user have reported the feature in order for it to be considered for implementation?

In both case this is where your comment about "why bother to report anything if it is going to dismissed out-of-hand" comes in.

BC

Hopefully there isn't too many such reports, generally good maintainers will have sent the people to the correct place for feature requests or if they were felling extra nice opened feature requests on there behalf in the right place.

New features don't belong in our bugtracker in almost all cases anyway.

And here is where I have to display my ignorance and ask: Why? Why don't "new features" belong here? Do we -- as in openSUSE, TW, and SLE -- only follow what other distros accept or come up with and we just "follow the pack"?

I suspect that I am misinterpreting what is meant by "new feauters don't belong in our bugtracker" so I would be most please if this could be explained to me -- in a private msg if required so as not to clutter up this thread.

BC

openSUSE as a distro takes a collection of software from various upstream sources take KDE as an example, if you would like a new feature in KDE or Thunderbird or any one of a number of pieces of software we ship, the new work for that feature is likely to be done by a KDE or Thunderbird etc developer not by the openSUSE packager. The better place for that new feature is whichever place KDE or Thunderbird ... use to track new features not our bugtracker. There are some exceptions like simple features related to integration with the operating system that probably do belong in bugzilla but as a general rule in most parts of openSUSE we try to keep as few differences with upstream as possible. For features that are "openSUSE" features rather then features for a specific application we have something called fate.opensuse.org, although most things that end up there don't get worked on for the simple fact that openSUSE is a community orginisation and you can't force someone else to do something for you. Most new features in openSUSE come from someone thinking it would be cool if openSUSE did this then going and doing the work to make that happen rather then someone posting an idea and someone else feeling like they should implement it. -- 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-08-02 03:39, Simon Lees wrote:

On 02/08/17 10:51, Basil Chupin wrote:

...

On 02/08/17 05:09, Carlos E. R. wrote:

...

On 2017-08-01 14:03, Werner Flamme wrote:

...

Carlos E. R. [01.08.2017 13:46]:

...

On 2017-08-01 13:18, Werner Flamme wrote:

...

Carlos E. R. [01.08.2017 13:15]: > On 2017-08-01 12:18, Axel Braun wrote:

I think what you arguing about is more relevant re another option which

...

Petr put forward, namely: "Wontfix/Feature: issue is a feature request/or something that should not be fixed by us".

If it isn't going to be "fixed by us" then who should "fix" the problem reported by a user?

If it is a "feature" requested by a user then to whom should the user have reported the feature in order for it to be considered for implementation?

In both case this is where your comment about "why bother to report anything if it is going to dismissed out-of-hand" comes in.

Hopefully there isn't too many such reports, generally good maintainers will have sent the people to the correct place for feature requests or if they were felling extra nice opened feature requests on there behalf in the right place.

New features don't belong in our bugtracker in almost all cases anyway.

Well, bugzilla has a "feature" field or option or whatever. And, maintainers will already know the proper contacts and handles to report upstream, whereas users don't. Yes, I have reported issues and requests upstream, too. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlmBoioACgkQja8UbcUWM1wVZgD/aoOenkEycATvzpZJlPUXf9zv RUrg7U4eAIoNJ6KQf8oA/j3qNaLsvLqhCk9tkzXSTcfb5l7sIWCQMPBYJrLotzuf =4ujz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 02/08/17 12:05, Felix Miata wrote:

Basil Chupin composed on 2017-08-02 11:21 (UTC+1000):

...

I think what you arguing about is more relevant re another option which Petr put forward, namely: "Wontfix/Feature: issue is a feature request/or something that should not be fixed by us". If it isn't going to be "fixed by us" then who should "fix" the problem reported by a user? If it is a "feature" requested by a user then to whom should the user have reported the feature in order for it to be considered for implementation? In both case this is where your comment about "why bother to report anything if it is going to dismissed out-of-hand" comes in. The artificial distinction between bug and feature is unfortunate WRT openSUSE triagers and users. Whether the benefits of separate trackers outweigh their costs WRT devs I have no idea. Bugzilla software offers tagging as "enhancement", which is how "features" in other Bugzilla installations are handled. In those if a bug report should classified as feature, a triager can simply change a check or select box to convert a bug report into a feature request, and vice versa.

Separate trackers as we have mean the trouble of assignee or triager closing the bug, explaining to the reporter what "should have been" or "should be" done, and leaving it to the perplexed reporter who may or may not appreciate any distinction between the concepts WRT his report to start all over elsewhere. Correspondingly, when someone decides to implement an existing feature, there are two reports to deal with, a fate to close, and a bug to implement and handle, using entirely different UIs for each.

Thanks for this explanation, Felix. Is this "Bugzilla" a 'commonly available' system or something specific to openSUSE/TW/SUSE and given the name 'Bugzilla'? 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

Basil Chupin composed on 2017-08-02 13:01 (UTC+1000):

Is this "Bugzilla" a 'commonly available' system or something specific to openSUSE/TW/SUSE and given the name 'Bugzilla'?

Bugzilla is software for tracking bugs: http://www.bugzilla.org/ Bugzilla is a generic term for web sites for tracking software development issues (commonly but far from always), through Bugzilla software. Examples: http://bugzilla.mozilla.org/ http://bugzilla.opensuse.org aka bugzilla.novell.com aka bugzilla.suse.com http://bugzilla.kernel.org/ http://bugzilla.redhat.com/ http://bugzilla.gnome.org/ http://bugzilla.samba.org/ http://bugzilla.xfce.org/ http://bugs.kde.org/ http://bugs.webkit.org/ http://bugs.freedesktop.org/ Xorg, GStreamer, PulseAudio & a lot more http://bugs.documentfoundation.org/ LibreOffice http://bugs.pearsoncomputing.net/ TDE (KDE3 fork) http://bugs.gentoo.org/ http://bugs.mageia.org/ http://bugs.eclipse.org/bugs/ http://bz.apache.org/ apache, openoffice, spamassassin, jira http://silk.apana.org.au/bugzilla/ FileCommander http://sourceware.org/bugzilla/ binutils, gcc, gdb, glibc, more -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- Per Jessen, Zürich (27.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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)" :

...

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

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:

...

...

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

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

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. If the number of unhandled bugs is so big, there is something very wrong going on.

...

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.

I like asking the reporter and leaving it with "needinfo", but it is more work than closing with "no longer under maintenance, please report if problem persists in a maintaned version".

But that tells me as a reporter that there is no interest on what I reported from the distribution. I have bumped often into people that refuse to report in bugzilla.

...

Have a quick look at the bug, decide case per case if something can be done.

The problem is - the sole reason we have this mountain of reports is that noone had the time or inclination to do just that.

Well, that is the real problem. The mountain is the symptom. Why then should I report bugs?

...

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.

We already have something like that - at least I have recently begun getting a weekly email from bugzilla titled "Your Bugzilla bug list needs attention.". I think this is when bugz assigned to me have had no activity for a week.

What happens if you no longer work on openSUSE things, died, or something? If the address is wrong? The emails are lost unless there is no supervisor told that there is no progress and who acts.

Anyway, that's for a later revamp of the bug-handling process, we should probably focus on $SUBJ for now.

Yes, but if we have to do this now, we are doing it wrong the entire process. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

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.

...

If the number of unhandled bugs is so big, there is something very wrong going on.

The number of open reports is that big, yes. See the original posting.

Well, IMHO the important thing is to find out why and correct that situation... then bub count will slowly diminish. Felix Miata pointed out that "A good working tracker also depends on reporters following up". So I had a look at my reports, saw some as old as 2009, and started reviewing them... From 11 so far, I think I closed 7, pinged 3, and another one I'm studying.

...

...

...

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.

I like asking the reporter and leaving it with "needinfo", but it is more work than closing with "no longer under maintenance, please report if problem persists in a maintaned version".

But that tells me as a reporter that there is no interest on what I reported from the distribution.

Yes, I know what you mean. I don't like it either. The problem is how to deal with this huge pile of reports, given a limited amount of resources, without offending people.

One by one :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

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. Now, if that bug is simply closed without investigation, the next bug that gets reported in that area will suffer the same fate: bit bucket.

...

...

...

If the number of unhandled bugs is so big, there is something very wrong going on.

The number of open reports is that big, yes. See the original posting.

Well, IMHO the important thing is to find out why and correct that situation... then bub count will slowly diminish.

Why - not enough people that deal with bug reports. Correction - get more people to deal with bug reports.

Or developers that ignore bug reports.

In the meantime, try to reduce the mountain by at least closing reports on versions no longer under maintenance.

If it is done summarily, that will piss the reporter a lot. If the bug does not exist on the new release, why was he not told that issue was solved? He might as well not report at all, issues are solved or not solved on their own after some years. Don't report, because nothing will change by reporting. Don't close summarily. If it takes months to do it properly, so be it: do it properly. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

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.

Hmm, maybe we are not talking about the same thing. Since 2008, I get automatic emails with every update to reports I have created, no matter who they are assigned to. I don't remember if that is an option I specifically enabled somewhere. -- Per Jessen, Zürich (21.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 02/08/17 08:16, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2017-08-01 23:42, Per Jessen wrote:

...

Carlos E. R. 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

On 2017-08-01 14:18, Per Jessen wrote: 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?

...

...

...

If the number of unhandled bugs is so big, there is something very wrong going on. The number of open reports is that big, yes. See the original posting. Well, IMHO the important thing is to find out why and correct that situation... then bub count will slowly diminish. Why - not enough people that deal with bug reports. Correction - get more people to deal with bug reports.

In the meantime, try to reduce the mountain by at least closing reports on versions no longer under maintenance.

I have read that there are people still running 13.1, which is one of the unsupported systems. What to do with the bugs reported by the people who are running that particular system (-- and same applies to the other unsupported systems in the list)? May I suggest that ONCE THIS THREAD has been discussed and final conclusions arrived at as to how to handle the bugs that this thread be also posted in other lists especially 'opensuse' and 'announce' so that as many people as possible are made aware of this matter. It wouldn't be a bad idea to broadcast this beyond these mail lists: in the wiki or the forums, for example. 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

On 02/08/17 12:11, Patrick Shanahan wrote:

...

I have read that there are people still running 13.1, which is one of the unsupported systems. What to do with the bugs reported by the people who are running that particular system (-- and same applies to the other unsupported systems in the list)? undoubtedly earlier than 13.1. but where do you draw the line? there is only so much time in the day and only so many capable of solving the bugs. remember that this is a "volunteer" posiiton, not business supported

* Basil Chupin [08-01-17 22:04]: [...] product.

what do you do when you need a part for an antique car which is out of production an no longer supported my the mfg?

it has to have a stopping point which must also consider need and manpower.

Not a very good example using an antique car to support your argument. One doesn't drive an antique everyday to either go to work or to go shopping. But the 13.1 version I mentioned is actually used in a working/production environment in a business (I believe) -- which is different to owning an antique car for the sake of owning an antique. It doesn't mean that I am blind to the fact that volunteers are involved in "fixing" the bugs, but with the number of bugs still "on the books" indicates that something has to be done re the present situation. Perhaps it needs for someone to be employed by SUSE to look after the bugs? The bugs obviously affect openSUSE, SLE, and Tumbleweed, all "flagships" of SUSE. There is already the precedent for this: Richard spends some of his paid-for time on openSUSE and Tumbelweed matters so why not have another employed person just to do some PR work by looking after the bugs situation? 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-08-02 05:06, Simon Lees wrote:

On 02/08/17 12:12, Basil Chupin wrote:

...

On 02/08/17 12:11, Patrick Shanahan wrote:

...

...

I have read that there are people still running 13.1, which is one of the unsupported systems. What to do with the bugs reported by the people who are running that particular system (-- and same applies to the other unsupported systems in the list)? undoubtedly earlier than 13.1. but where do you draw the line?

* Basil Chupin [08-01-17 22:04]: [...] there is only so much time in the day and only so many capable of solving the bugs. remember that this is a "volunteer" posiiton, not business supported product.

what do you do when you need a part for an antique car which is out of production an no longer supported my the mfg?

it has to have a stopping point which must also consider need and manpower.

Not a very good example using an antique car to support your argument. One doesn't drive an antique everyday to either go to work or to go shopping.

But the 13.1 version I mentioned is actually used in a working/production environment in a business (I believe) -- which is different to owning an antique car for the sake of owning an antique.

It doesn't mean that I am blind to the fact that volunteers are involved in "fixing" the bugs, but with the number of bugs still "on the books" indicates that something has to be done re the present situation.

Perhaps it needs for someone to be employed by SUSE to look after the bugs? The bugs obviously affect openSUSE, SLE, and Tumbleweed, all "flagships" of SUSE. There is already the precedent for this: Richard spends some of his paid-for time on openSUSE and Tumbelweed matters so why not have another employed person just to do some PR work by looking after the bugs situation?

BC

Well the community has decided with its actions to only support so much and so far back (Evergreen tried to support more but didn't have the manpower). At the moment the community has a clear list of which operating systems they will support for how long, bugs outside that time frame simply won't be fixed if for no other reason then the infrastructure to build and package applications for those older OS's have been switched off. So if the bug is not likely to effect newer versions that are supported there is no reason to keep them open.

Yet those bugs were reported when those distributions were supported, but they were not solved. Sometimes they tried and were solved on another release, but others they were ignored. The dates to determine if the bug is valid re a valid release should be the time of report, not the current time. At least try to put some effort into it before closing with a "sorry, unmaintained release". Obviously a bug reported out of the time window should not be handled.

I think you'll find most of the open bugs are in packages that are not supported by SUSE (The SUSE list of supported packages is much smaller then openSUSE), because generally if a bug is in openSUSE its probably also in SUSE and worth fixing for our customers and the fix will also go to openSUSE (especially common now that Leap exists).

Understandable :-)

From looking at who announced this I suspect a number of SUSE employees will be contributing to the effort here and that this post was a invitation for members of the community to join us as well.

Yesterday I closed at least 7 and pushed another 3. ;-) Today I don't have access to my main computer. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlmBpeoACgkQja8UbcUWM1zpywD+L9cJ7TKZaxUiY14XpglSDDdW SUtalXxgXhdoE4TOveMA/1MrZ/1iVWZVcpYlBN4fHtITd7St2x2nuI2z1ATaEbSV =h12D -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday, 2 August 2017 4:02 Basil Chupin wrote:

I have read that there are people still running 13.1, which is one of the unsupported systems. What to do with the bugs reported by the people who are running that particular system (-- and same applies to the other unsupported systems in the list)?

I'm pretty sure there are, after all, I was one of them untill less than 3 months ago. But while I'm not really a fan of burning the bridges as soon as a distribution goes out of support (e.g. the bot nudging people to drop build targets from their projects - in opt-out manner to boot), I always understood that when I decide to keep using no longer supported distribution version, I'm on my own. From the technical point of view, even if someone fixes the bug, the fix won't be released in the form of an update anyway (of course, OBS makes it really easy to build patched package and even create one's own repository of such packages). Add the fact that most developers wouldn't have a 13.1 (or even older) system for testing. In general, it would be more useful to check if the issue persists in newer (supported) systems and work on it only if it does. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Carlos E. R. [08-02-17 06:21]:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2017-08-02 10:09, Michal Kubecek wrote:

...

On Wednesday, 2 August 2017 4:02 Basil Chupin wrote:

...

I have read that there are people still running 13.1, which is one of the unsupported systems. What to do with the bugs reported by the people who are running that particular system (-- and same applies to the other unsupported systems in the list)?

I'm pretty sure there are, after all, I was one of them untill less than 3 months ago. But while I'm not really a fan of burning the bridges as soon as a distribution goes out of support (e.g. the bot nudging people to drop build targets from their projects - in opt-out manner to boot), I always understood that when I decide to keep using no longer supported distribution version, I'm on my own.

Certainly.

Yet people holding into old releases often have no option. For instance, I keep an old laptop on 13.1 because it is 32 bit. It has an USB bug, and obviously I don't expect a patch; I don't even ask for it, and besides, I made my own workaround ;-)

so the "argument for" and "expectation" of support for out-of-maintenance systems should be considered "nil" and any more conversation along this line should cease and the fact there are unresolved and/or not investigated bugs that do not exist in later maintained releases is immaterial. if you choose to continue running out-of-maintenance releases, you are doing "your own thing". -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-08-02 14:02, Axel Braun wrote:

Stretching this a little more....the oldest bug in my list is confirmed against openSUSE 11.1, but still unsolved. Last change: 22 Apr 2010.

I feel these old bugs (= before last Evergreen 13.1) should be closed mechanically.

Objections?

I have objected already to that. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlmBwEMACgkQja8UbcUWM1wstwD/afCXDLumzHtuUPw/jsvJ1sFb 9OvM7IqgNO+zkuNJnA0A/3ez0dwdbDOXHlR7fj9zZt4w033AktZM4Uk32UK4Nxgx =QNRA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-08-02 14:25, Mari Donkers wrote:

On 02-08-17 12:18, Carlos E. R. wrote:

...

Yet people holding into old releases often have no option. For instance, I keep an old laptop on 13.1 because it is 32 bit.

Isn't Tumbleweed 32-bit an option? I'm contemplating installing this on my parents' computer someday because their Zorin OS 9 Lite Linux will go EOL in 2019.

Not for long. Firefox has already problems with 32 bits. I don't expect 32 bit TW to last much longer. Besides, I don't like TW in terms of maintenance (too much work). But this is OT for this thread - feel free to open a new thread if you are interested. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlmBxZsACgkQja8UbcUWM1xf0QD+KmBY6ZRxgIC4UO32AgoODq3c xWzd4u93elSku19kGgMA/056OzkVFhAu2uueCujzcShG0N4u6CIoAu2k2u6W2n2p =rAit -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2017-08-01 13:34, Per Jessen 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?

Persuade the reporters to retry on newer version and move the bug. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

On Tuesday 2017-08-01 13:34, Per Jessen 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?

Persuade the reporters to retry on newer version and move the bug.

I thought that's what I wrote in the paragraph you omitted? -- Per Jessen, Zürich (27.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Anton Aylward wrote:

On 01/08/17 07:34 AM, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2017-08-01 12:18, Axel Braun 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.

It occurs to me that there may be bugs, some of them as code, some not, that 'persist', and a fix in a later release could be applied to the earlier release.

Absolutely.

I think that would be a cleaner, more gratifying resolution that a wild card "WONTFIX Because no Longer Under maintenance".

What exactly would you do?

At the very least it will trigger mail to concerned parties that will see that the group is making an effort, even if somewhat belated. I think this is better PR than saying what amount to "we ignored you then and we still don't care".

I think you've hit the nail on the head here - better PR is what this need to be about, yes. -- Per Jessen, Zürich (29.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2017-08-01 16:45, Anton Aylward wrote:

On 01/08/17 07:34 AM, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2017-08-01 12:18, Axel Braun 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.

It occurs to me that there may be bugs, some of them as code, some not, that 'persist', and a fix in a later release could be applied to the earlier release.

I think that would be a cleaner, more gratifying resolution that a wild card "WONTFIX Because no Longer Under maintenance".

At the very least it will trigger mail to concerned parties that will see that the group is making an effort, even if somewhat belated. I think this is better PR than saying what amount to "we ignored you then and we still don't care".

Exactly. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-08-01 18:47, Felix Miata wrote:

Carlos E. R. composed on 2017-08-01 13:15 (UTC+0200):

...

Axel Braun wrote:

...

...

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?

A good working tracker also depends on reporters following up. If the bug didn't get touched while the release it affects was supported, and reporter has switched to a supported release in which reporter can reproduce, reporter should update the bug to the current release and not wait on triagers, QA or assignee to notice. If the bug amounts to a blocker WRT to the reporter, he should note that too. IOW, reporters shouldn't wait for activity that may or may not occur if they care about their own reports.

The reporter has to find some way to work around the bug, if it affects him, so probably he does not see it happening. After reporting, there is nothing more he can do to solve the issue except waiting. Which is what I do. I don't usually nag people "what about my issue?" every month. I just looked, and I have open reports going back to 2009. I will try to close some myself. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-08-01 21:51, Carlos E. R. wrote:

On 2017-08-01 18:47, Felix Miata wrote:

...

Carlos E. R. composed on 2017-08-01 13:15 (UTC+0200):

...

Axel Braun wrote:

...

...

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?

A good working tracker also depends on reporters following up. If the bug didn't get touched while the release it affects was supported, and reporter has switched to a supported release in which reporter can reproduce, reporter should update the bug to the current release and not wait on triagers, QA or assignee to notice. If the bug amounts to a blocker WRT to the reporter, he should note that too. IOW, reporters shouldn't wait for activity that may or may not occur if they care about their own reports.

The reporter has to find some way to work around the bug, if it affects him, so probably he does not see it happening. After reporting, there is nothing more he can do to solve the issue except waiting. Which is what I do. I don't usually nag people "what about my issue?" every month.

I just looked, and I have open reports going back to 2009. I will try to close some myself.

I reviewed 11 of my bugs so far, closed a bunch, renewed two or three. I stopped at one that I have to investigate further. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-08-01 13:52, Vojtěch Zeisek wrote:

Dne úterý 1. srpna 2017 12:18:24 CEST, Axel Braun napsal(a):

...

Am 31. Juli 2017 16:54:06 MESZ schrieb "Petr Hodac (Hody)" :

...

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.

definitely a good idea!

Yes!

...

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)

This is not good idea how to encourage users to report bugs...

...

- review each bug and request for verification in newer releases: more work but shows committment

KDE (or part of it) recently did something similar. I received from its bugzilla e-mails like "this bug was reported only for KDE4/some other old version, we are going to close it if it is not present in recent KF5". If this is the only activity in the bug during past year or so, it is really very frustrating and discouraging... I don't argue against the cleanup, but, please, the bugs must be really reviewed before closing and the closing comment may not discourage user from new report. And please, do not adopt Fedora batch-closing style. Other point worth of discussion is why are there so many opened bugs?

I agree completely. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Per Jessen píše v Út 01. 08. 2017 v 12:20 +0200:

Petr Hodac (Hody) wrote:

...

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.

See the following table for yourself: openSUSE Tumbleweed 1633 openSUSE Leap 42.3 9 openSUSE Leap 42.2 220 openSUSE Leap 42.1 280 openSUSE 13.2 0

There seems to be no specific bugzilla product "openSUSE 13.2", but if you search for openSUSE and version 13.2, there are 388 open bug reports.

Nice, Per could you please share the full bugzie query link for Petr? We can update the content we will provide for the hunting. Also if you think there is specific product/tech query that has shitload^Wmany bugs feel free to share them, we can include them in the lists of course. Cheers Tom