Hi all,
Today, I stumbled upon OPEN bugs [1] link on Upstream Release Monitoring wiki page [2]. And the BZ/packages probably deserves cleanup. There are several categories I identified as worrying:
1) Packages are retired but the bugs are kept open. For example:
xorg-x11-drv-{mouse,sisusb, ...} opengrok
2) Packages are not updated in ages, although newer version exists:
bouml ovaldi
3) Packages are updated, but the bug is kept open
gobject-introspection rsyslog
I would suggest probably to close the bugs for 1st category, the packages from 2nd category should be orphaned and the packages from 3rd category should not be monitored anymore. Any thoughts?
Vít
[1] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGN...
[2] https://fedoraproject.org/wiki/Upstream_release_monitoring
ovaldi maintainer here. Will update it as soon as possible.
Last time when I tried the update, it's incompatible with rpm 4.12+...
On Wed, 2 Sep 2015, Vít Ondruch wrote:
- Packages are updated, but the bug is kept open
I would suggest probably to close the bugs for 1st category, the packages from 2nd category should be orphaned and the packages from 3rd category should not be monitored anymore. Any thoughts?
I would keep monitoring for 3) but close onesting bugs that are too old and were clearly forgotten. I prefer to be informed by the monitor script, even if I am a version behind :)
I've also just now added comments for all my entries on why these are still not in CLOSED state.
Paul
Vít
[1] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGN...
[2] https://fedoraproject.org/wiki/Upstream_release_monitoring
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Dne 2.9.2015 v 16:10 Paul Wouters napsal(a):
On Wed, 2 Sep 2015, Vít Ondruch wrote:
- Packages are updated, but the bug is kept open
I would suggest probably to close the bugs for 1st category, the packages from 2nd category should be orphaned and the packages from 3rd category should not be monitored anymore. Any thoughts?
I would keep monitoring for 3) but close onesting bugs that are too old and were clearly forgotten. I prefer to be informed by the monitor script, even if I am a version behind :)
Yes (3) is a bit tricky. I can imagine, that some maintainers probably don't want to close that bug and keep it updated all the time, since BZ sends notifications and that might be enough. Moreover, even change the state to ASSIGNED makes the-new-hotness to open new ticket [1] :/. But I doubt that it is useful for stuff like "gobject-introspection" since I assume this is part of "Gnome megaupdates" (I might be wrong about this).
Vít
[1] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGN...
I've also just now added comments for all my entries on why these are still not in CLOSED state.
Thx, thats great!
Vít
On 2015-09-02, Vít Ondruch vondruch@redhat.com wrote:
Dne 2.9.2015 v 16:10 Paul Wouters napsal(a):
On Wed, 2 Sep 2015, Vít Ondruch wrote:
- Packages are updated, but the bug is kept open
I would suggest probably to close the bugs for 1st category, the packages from 2nd category should be orphaned and the packages from 3rd category should not be monitored anymore. Any thoughts?
I would keep monitoring for 3) but close onesting bugs that are too old and were clearly forgotten. I prefer to be informed by the monitor script, even if I am a version behind :)
Yes (3) is a bit tricky. I can imagine, that some maintainers probably don't want to close that bug and keep it updated all the time, since BZ sends notifications and that might be enough.
Those mainatainers can enable sending e-mails in FMN and disable reporting bugs in PKGDB.
-- Petr
On 09/02/2015 06:49 AM, Vít Ondruch wrote:
Hi all,
Today, I stumbled upon OPEN bugs [1] link on Upstream Release Monitoring wiki page [2]. And the BZ/packages probably deserves cleanup. There are several categories I identified as worrying:
Packages are retired but the bugs are kept open. For example:
Packages are not updated in ages, although newer version exists:
Packages are updated, but the bug is kept open
I would suggest probably to close the bugs for 1st category, the packages from 2nd category should be orphaned and the packages from 3rd category should not be monitored anymore. Any thoughts?
I agree with the first two. Need some criteria for how "ages" is defined though.
As for 3, I have a couple packages that update frequently and I prefer to just leave the tracking bug open let it update, thus doing my part to preserve precious positive integers :). Perhaps adding the Tracking keyword could be helpful here somehow?