[opensuse-project] Zombie bugzilla entries
Hi, recently, I've been crawling through open bugzilla entries and found out few which are being years unattended. I investigated further and there are few problems tightly connected to that. 1) There are open bncs against no longer maintained releases. 10.2+10.3+11.0 reported bugs count is 803 now. These reports are years old and doesn't fit to the current codebase and hence should be mostly closed. This obviously won't help anything since there will accumulate similarly useless (from the code perspective) reports after some time again. A solution is to close these automatically right after the product which they are reported against become unmaintained. The ones which still can be reproduced in later releases would be reopened manually by reporters. This is how fedora bugs are handled. 2) Assigned entries, even though they are P1, even though there are patches with fixes attached, are not taken care of. There is 1572 of all opensuse bugs which are left for more than 400 days without any attention. Many of them are not even reassigned to proper maintainers. Both of these poblems currently suck, because reporters are noticed after 3 years that we close their report without bothering to reply them in any way. Any ideas how to improve these bugzilla stats? Does the proposed "solution" sound OK? thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2010-11-12 at 20:42 +0100, Jiri Slaby wrote:
A solution is to close these automatically right after the product which they are reported against become unmaintained.
This is alienating to us reporters.
2) Assigned entries, even though they are P1, even though there are
And closing these is even more alienating.
Any ideas how to improve these bugzilla stats? Does the proposed "solution" sound OK?
The solution would be to solve them in time. Doing differently is no solution, is a hack. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkzeAuwACgkQtTMYHG2NR9WZVgCePLUmvN5vGQDjDEH5kI6+6Qhi epYAnjrrZ3860gjDkSYeFDB7eNgaECkz =wY2o -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Saturday November 13 2010 04:15:55 Carlos E. R. wrote:
On Friday, 2010-11-12 at 20:42 +0100, Jiri Slaby wrote:
A solution is to close these automatically right after the product which they are reported against become unmaintained.
This is alienating to us reporters.
While I agree that this might be alienating there's also the task to do some house keeping in Bugzilla. Sure, if some bug didn't get fixed it is sad but until it can be reproduced against some supported version that bug should be seen as gone for good. Open question might be how many people can be arsed to try to reproduce such things in newer versions...
2) Assigned entries, even though they are P1, even though there are
And closing these is even more alienating.
No, those shouldn't be closed but the respective maintainers should get their ass kicked to take care of their packages. That is either apply the patch and send it upstream or close the bug with some sensitive reason.
Any ideas how to improve these bugzilla stats? Does the proposed "solution" sound OK?
The solution would be to solve them in time. Doing differently is no solution, is a hack.
Sure, that is easy to say and valid for the "patch is available" bugs but for the rest not. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Lørdag den 13. november 2010 04:49:29 skrev Stephan Kleine:
On Saturday November 13 2010 04:15:55 Carlos E. R. wrote:
On Friday, 2010-11-12 at 20:42 +0100, Jiri Slaby wrote:
A solution is to close these automatically right after the product which they are reported against become unmaintained.
This is alienating to us reporters.
While I agree that this might be alienating there's also the task to do some house keeping in Bugzilla.
I don't think it'd be unfair to close the reports, and ask people to re-open if they can reproduce it on a supported version. Either people are already running a newer, supported version and can easily try to reproduce there, or they've moved to a different system, and won't care what happens to their bug report anyway. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi; On Sat, Nov 13, 2010 at 11:06 AM, Martin Schlander <martin.schlander@gmail.com> wrote:
Lørdag den 13. november 2010 04:49:29 skrev Stephan Kleine:
On Saturday November 13 2010 04:15:55 Carlos E. R. wrote:
On Friday, 2010-11-12 at 20:42 +0100, Jiri Slaby wrote:
A solution is to close these automatically right after the product which they are reported against become unmaintained.
This is alienating to us reporters.
While I agree that this might be alienating there's also the task to do some house keeping in Bugzilla.
I don't think it'd be unfair to close the reports, and ask people to re-open if they can reproduce it on a supported version.
Either people are already running a newer, supported version and can easily try to reproduce there, or they've moved to a different system, and won't care what happens to their bug report anyway.
From my experience, doing this is in an automated way can be bad,
people will feel ignored. If someone triages the bug and closes it, that would be much better. Regards, ismail -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LNX.2.00.1011131556050.28022@Telcontar.valinor> On Saturday, 2010-11-13 at 11:16 +0200, İsmail Dönmez wrote:
Hi;
On Sat, Nov 13, 2010 at 11:06 AM, Martin Schlander <> wrote:
Lørdag den 13. november 2010 04:49:29 skrev Stephan Kleine:
On Saturday November 13 2010 04:15:55 Carlos E. R. wrote:
On Friday, 2010-11-12 at 20:42 +0100, Jiri Slaby wrote:
A solution is to close these automatically right after the product which they are reported against become unmaintained.
This is alienating to us reporters.
While I agree that this might be alienating there's also the task to do some house keeping in Bugzilla.
At least say that you are sorry. Be human, not machine. Having an automated process that closes reports without ever working on them, signals that you do not care. Otherwise, that reporter will not bother to report again anything.
Either people are already running a newer, supported version and can easily try to reproduce there, or they've moved to a different system, and won't care what happens to their bug report anyway.
From my experience, doing this is in an automated way can be bad, people will feel ignored. If someone triages the bug and closes it, that would be much better.
Absolutely. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkzeqQIACgkQtTMYHG2NR9UQvgCeOsTlevSFap+LUv5fNHhAr6JO Me4An1IBfDKW93lTnu1f79waezLnK1OL =5ezU -----END PGP SIGNATURE-----
Hi there,
2) Assigned entries, even though they are P1, even though there are patches with fixes attached, are not taken care of. There is 1572 of all opensuse bugs which are left for more than 400 days without any attention. Many of them are not even reassigned to proper maintainers.
We have to assign them to the current maintainers and they should evaluate them during the next hack week or bugzilla clean week or so, The Fedora way is not friendly at all. If the maintainer could not decide the state of the issue, they could change product version to current or developer release and set to "needinfo" for the reporter and/or add them as Junior Jobs bug for reproduce or evaluate for the current stable or development release. best kalman -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 11/13/2010 07:39 AM, Kálmán Kéménczy wrote:
Hi there,
2) Assigned entries, even though they are P1, even though there are patches with fixes attached, are not taken care of. There is 1572 of all opensuse bugs which are left for more than 400 days without any attention. Many of them are not even reassigned to proper maintainers.
We have to assign them to the current maintainers and they should evaluate them during the next hack week or bugzilla clean week or so,
The Fedora way is not friendly at all. If the maintainer could not decide the state of the issue, they could change product version to current or developer release and set to "needinfo" for the reporter and/or add them as Junior Jobs bug for reproduce or evaluate for the current stable or development release.
Ok, but note that there are bncs that are not changed/fixed even though there is enough of data (patches, great debug info provided etc.). The bugs are not fixed and closed though. That falls exactly to the case 2). It looks like "we asked you for some info and we don't care anymore". Many of bugs I reported ended up in this state. Examples are broken intel graphics since 11.3 (but I'm at least reminded to test the latest release every 2 months or so), reported bug in nmap with exact line number and described error. The same for libacl. Vim parses the gcc output wrong since we use gcc 4.5 and many others. The last four are fixable in an hour, but the assigned people don't care for years. I'm not counting gnome bugs which are assigned for years to gnome screening team and are not touched at all by anybody. I don't think anybody will report any more bugs if they experience this behaviour once. Another thing is that we have reports from milestones and RCs, but we go through them after we release GA. What are the testing releases good for if we don't even try to fix the reported issues? (I fixed many such kernel bncs for 11.3 RCs recently.) Some once-a-year happening like whatever-week won't improve this at all. Some constructive comments. I still think we should close bugs which are a) untouched for years AND b) are against unmaintained codebases. It should be noted there, that we are closing it because it is unsupported product and if the bugs still persist in later releases, we want reporters to reopen. Otherwise we will have thousands of rotten entries. Further we need people who will regularly assign bugs to proper developers/maintainers. This is not easy. I personally have problems to guess the correct person. I use osc maintainer, osc log, dig info out of osc metas and internal novell wiki (kernel maintainers are specified there for kernel components). It would be great if there was one reliable method/tool. As none of those above returns the proper person and bugs happen to be without progress. It it also because some assignees don't care. No, they should be forced to reassign appropriately (or reassign back to screening lists) if they know nothing about the package. regards, -- js suse labs -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Many of bugs I reported ended up in this state. Examples are broken intel graphics since 11.3 (but I'm at least reminded to test the latest release every 2 months or so), reported bug in nmap with exact line number and described error. The same for libacl. Vim parses the gcc output wrong since we use gcc 4.5 and many others. The last four are fixable in an hour, but the assigned people don't care for years. I'm not counting gnome bugs which are assigned for years to gnome screening team and are not touched at all by anybody.
In that case QA should step in! every bug has a QA member, we have to ask them ehat is the problem, how can we help to move forward, should we change some process or what is their opinion?
I don't think anybody will report any more bugs if they experience this behaviour once.
agree another thing what I don't like, when assignee route me to the upstream. If I am a user and use openSUSE and report a bug, I don't want to go anywhere else to create an issue in another bugzilla. Maintainer should care about my reported issue through upstream and back to the distribution.
Another thing is that we have reports from milestones and RCs, but we go through them after we release GA. What are the testing releases good for if we don't even try to fix the reported issues? (I fixed many such kernel bncs for 11.3 RCs recently.) Some once-a-year happening like whatever-week won't improve this at all.
Maybe someone in that list could answer for that questions...
Some constructive comments. I still think we should close bugs which are a) untouched for years AND b) are against unmaintained codebases. It should be noted there, that we are closing it because it is unsupported product and if the bugs still persist in later releases, we want reporters to reopen. Otherwise we will have thousands of rotten entries.
I agree. But we should clarify this is for just for kick-off and we will never ever do it again.
Further we need people who will regularly assign bugs to proper developers/maintainers. This is not easy. I personally have problems to guess the correct person. I use osc maintainer, osc log, dig info out of osc metas and internal novell wiki (kernel maintainers are specified there for kernel components). It would be great if there was one reliable method/tool. As none of those above returns the proper person and bugs happen to be without progress.
QA should care about it. Maybe we have to create a list about the positions/maintainers/roles which is not assigned to anyone. best k -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Sun, Nov 14, 2010 at 11:22:03AM +0100, Kálmán Kéménczy wrote:
Many of bugs I reported ended up in this state. Examples are broken intel graphics since 11.3 (but I'm at least reminded to test the latest release every 2 months or so), reported bug in nmap with exact line number and described error. The same for libacl. Vim parses the gcc output wrong since we use gcc 4.5 and many others. The last four are fixable in an hour, but the assigned people don't care for years. I'm not counting gnome bugs which are assigned for years to gnome screening team and are not touched at all by anybody.
In that case QA should step in! every bug has a QA member, we have to ask them ehat is the problem, how can we help to move forward, should we change some process or what is their opinion?
qa@suse.de really is a virtual team... Consisting of 0 (zero) people for openSUSE in Bugzilla context. There is some community testing team led by Holgi as far as I know, but I am not sure it takes care of reviewing bugzilla entries. The bnc-team-screening team are 1 or 2 chinese QA engineers that assign bugs away from the screening address to the maintainers. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
In that case QA should step in! every bug has a QA member, we have to ask them ehat is the problem, how can we help to move forward, should we change some process or what is their opinion?
qa@suse.de really is a virtual team... Consisting of 0 (zero) people for openSUSE in Bugzilla context.
There is some community testing team led by Holgi as far as I know, but I am not sure it takes care of reviewing bugzilla entries.
The bnc-team-screening team are 1 or 2 chinese QA engineers that assign bugs away from the screening address to the maintainers.
In that case we need a QA team! you can count on me if needed :) best k -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Marcus Meissner wrote:
On Sun, Nov 14, 2010 at 11:22:03AM +0100, Kálmán Kéménczy wrote:
Many of bugs I reported ended up in this state. Examples are broken intel graphics since 11.3 (but I'm at least reminded to test the latest release every 2 months or so), reported bug in nmap with exact line number and described error. The same for libacl. Vim parses the gcc output wrong since we use gcc 4.5 and many others. The last four are fixable in an hour, but the assigned people don't care for years. I'm not counting gnome bugs which are assigned for years to gnome screening team and are not touched at all by anybody.
In that case QA should step in! every bug has a QA member, we have to ask them ehat is the problem, how can we help to move forward, should we change some process or what is their opinion?
qa@suse.de really is a virtual team... Consisting of 0 (zero) people for openSUSE in Bugzilla context.
There is some community testing team led by Holgi as far as I know, but I am not sure it takes care of reviewing bugzilla entries.
There is a community-screening list address, but I have never seen anything posted there.
The bnc-team-screening team are 1 or 2 chinese QA engineers that assign bugs away from the screening address to the maintainers.
What does 'bnc' mean? How about the process flow - surely we have some existing (even if long outdated) process for how bugs are processed? Given the reported state of things, I'm guessing this process has largely fallen apart. -- Per Jessen, Zürich (11.8°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Am Sonntag 14 November 2010 schrieb Per Jessen:
Marcus Meissner wrote:
On Sun, Nov 14, 2010 at 11:22:03AM +0100, Kálmán Kéménczy wrote:
Many of bugs I reported ended up in this state. Examples are broken intel graphics since 11.3 (but I'm at least reminded to test the latest release every 2 months or so), reported bug in nmap with exact line number and described error. The same for libacl. Vim parses the gcc output wrong since we use gcc 4.5 and many others. The last four are fixable in an hour, but the assigned people don't care for years. I'm not counting gnome bugs which are assigned for years to gnome screening team and are not touched at all by anybody.
In that case QA should step in! every bug has a QA member, we have to ask them ehat is the problem, how can we help to move forward, should we change some process or what is their opinion?
qa@suse.de really is a virtual team... Consisting of 0 (zero) people for openSUSE in Bugzilla context.
There is some community testing team led by Holgi as far as I know, but I am not sure it takes care of reviewing bugzilla entries.
There is a community-screening list address, but I have never seen anything posted there. If we have enough people caring for it - and really taking responsiblity, I'm very happy to take away the bnc-team-screening assignees to a list as such. The bnc-team-screening is really not doing a great job and if we put this right in the hands of people caring, I think we would gain also a way that is accepted by developers and users if this screening/QA team decides a bug can be closed.
The bnc-team-screening team are 1 or 2 chinese QA engineers that assign bugs away from the screening address to the maintainers.
What does 'bnc' mean?
bugzilla.novell.com Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-11-14 at 11:22 +0100, Kálmán Kéménczy wrote:
another thing what I don't like, when assignee route me to the upstream. If I am a user and use openSUSE and report a bug, I don't want to go anywhere else to create an issue in another bugzilla. Maintainer should care about my reported issue through upstream and back to the distribution.
Absolutely! - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkzf3gEACgkQtTMYHG2NR9XTFQCfccnLZY1Xppl8FRv4WAs0fisn PT0An2p8D6bnC4Ug+ScwvvgijsPUZ/r2 =0BNn -----END PGP SIGNATURE-----
Am Samstag 13 November 2010 schrieb Kálmán Kéménczy:
Hi there,
2) Assigned entries, even though they are P1, even though there are patches with fixes attached, are not taken care of. There is 1572 of all opensuse bugs which are left for more than 400 days without any attention. Many of them are not even reassigned to proper maintainers.
We have to assign them to the current maintainers and they should evaluate them during the next hack week or bugzilla clean week or so, Finding the "current maintainer" is a task in itself that is often not done.
I have a pet bug assigned to me, I'm happy if you understand and explain to the "current maintainer": https://bugzilla.novell.com/show_bug.cgi?id=643277 And we can create as many openSUSE bugzilla clean weeks as we like, if the people having the bugs assigned just don't care, there is a problem we have almost no way to fix unless other people volunteer to fix it (this is the same with every open source project I'm aware of that exceeds a certain limit on users per developer). So the question comes down to: continue to ignore the problem and pile up old bugs or start cleaning up and nagging/reminding assignees for important bugs and close the unimportant bugs? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Saturday 13 November 2010 07:39:22 Kálmán Kéménczy wrote:
Hi there,
2) Assigned entries, even though they are P1, even though there are patches with fixes attached, are not taken care of. There is 1572 of all opensuse bugs which are left for more than 400 days without any attention. Many of them are not even reassigned to proper maintainers.
We have to assign them to the current maintainers and they should evaluate them during the next hack week or bugzilla clean week or so,
The Fedora way is not friendly at all. If the maintainer could not decide the state of the issue, they could change product version to current or developer release and set to "needinfo" for the reporter and/or add them as Junior Jobs bug for reproduce or evaluate for the current stable or development release.
Looking at the numbers, I think maintainers and teams need help with these bugs, they should not stay open anymore. So, I see two ways: * Closing those bug in an automatic way with a friendly message * Creation of a team that takes care of bugs and helps out Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi, Le lundi 15 novembre 2010, à 11:20 +0100, Andreas Jaeger a écrit :
On Saturday 13 November 2010 07:39:22 Kálmán Kéménczy wrote:
Hi there,
2) Assigned entries, even though they are P1, even though there are patches with fixes attached, are not taken care of. There is 1572 of all opensuse bugs which are left for more than 400 days without any attention. Many of them are not even reassigned to proper maintainers.
We have to assign them to the current maintainers and they should evaluate them during the next hack week or bugzilla clean week or so,
The Fedora way is not friendly at all. If the maintainer could not decide the state of the issue, they could change product version to current or developer release and set to "needinfo" for the reporter and/or add them as Junior Jobs bug for reproduce or evaluate for the current stable or development release.
Looking at the numbers, I think maintainers and teams need help with these bugs, they should not stay open anymore.
So, I see two ways: * Closing those bug in an automatic way with a friendly message * Creation of a team that takes care of bugs and helps out
We proposed to organize a bug day to help with this, and it will happen next Saturday. Alexander put some details on his blog: http://lizards.opensuse.org/2010/11/22/bugday/ Please join! We'll send more details on how to help before the bug day :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Jiri Slaby wrote:
Any ideas how to improve these bugzilla stats? Does the proposed "solution" sound OK?
I second what Carlos, Ismail and Kalman have said, and I'd like to add that we need a further proposal for how to avoid ending up in the same situation again. I.e. how do we, as a project, handle bugreporting? I've worked with bug reporting/management systems throughout my professional career, both on customer and vendor side, but I'm not sure if the approaches used there would be suitable in a volunteer project. Regardless, a largely unmanaged (2300+ orphaned bugs) bugreporting system is not good for quality, even less so for encouraging people to keep reporting bugs. -- Per Jessen, Zürich (13.6°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
and I'd like to add that we need a further proposal for how to avoid ending up in the same situation again. I.e. how do we, as a project, handle bugreporting?
yes, this is more important. there should be a cleanup process after every release and after every EOL.
Regardless, a largely unmanaged (2300+ orphaned bugs) bugreporting system is not good for quality, even less so for encouraging people to keep reporting bugs.
agree, we need those guys, who spend their times to report an issue. k -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Sat, Nov 13, 2010 at 05:01:35PM +0100, Per Jessen wrote:
Jiri Slaby wrote:
Any ideas how to improve these bugzilla stats? Does the proposed "solution" sound OK?
I second what Carlos, Ismail and Kalman have said, and I'd like to add that we need a further proposal for how to avoid ending up in the same situation again. I.e. how do we, as a project, handle bugreporting?
I've worked with bug reporting/management systems throughout my professional career, both on customer and vendor side, but I'm not sure if the approaches used there would be suitable in a volunteer project.
Regardless, a largely unmanaged (2300+ orphaned bugs) bugreporting system is not good for quality, even less so for encouraging people to keep reporting bugs.
A lot of them are assigned to bnc-team-gnome, bnc-team-mozilla, and various other GNOME and KDE developers (sreeves,federico,wstephenson et.al.). Perhaps the GNOME and KDE teams could step forward and screen their bugs (better). Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi! Am Freitag, 12. November 2010, 20:42:38 schrieb Jiri Slaby:
Hi,
recently, I've been crawling through open bugzilla entries and found out few which are being years unattended. I investigated further and there are few problems tightly connected to that.
1) There are open bncs against no longer maintained releases. 10.2+10.3+11.0 reported bugs count is 803 now. These reports are years old and doesn't fit to the current codebase and hence should be mostly closed. This obviously won't help anything since there will accumulate similarly useless (from the code perspective) reports after some time again.
A solution is to close these automatically right after the product which they are reported against become unmaintained. The ones which still can be reproduced in later releases would be reopened manually by reporters. This is how fedora bugs are handled.
I think automatically closing bugs is not good. But as already suggested by others, e.g. Martin, I think it is fine to ask the reporter if he or she can still reproduce a bug with a current version. If you get no response close the bug after some time (e.g. 4 weeks), otherwise move it to a maintained release. Of course you will probably close some still valid bugs this way, but I think it is probably worth to do so to get the number of reports still manageable. This at least is what we are doing for bugs assigned to kde-maintainers. This helped us to get the number of open bugs down from more than 500 (some time in 2009) to less than 300 (roughly 200 of them for 11.3). (Still too much in my opinion to be really good to handle.) Christian -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (12)
-
Andreas Jaeger -
Carlos E. R. -
Christian Trippe -
İsmail Dönmez -
Jiri Slaby -
Kálmán Kéménczy -
Marcus Meissner -
Martin Schlander -
Per Jessen -
Stephan Kleine -
Stephan Kulow -
Vincent Untz