Red Hat Bugzilla – Bug 684364
[RFE] Don't submit reports for obsolete products. Instead ask users to upgrade
Last modified: 2014-02-02 17:15:22 EST
We're still getting a fair amount of abrt reports for Fedora 12. Most of these bugs are useless, since there's no way we can act on them for Fedora 12. It would be nice if abrt would first check to see if the Fedora version is EOL, and if so, ask the user to upgrade.
Filing against Fedora 13, since this would be nice to backport into the earliest stable release we still can.
Well there is no way how ABRT can know that the release is obsolete, I think the proper way would be to block EOLed releases on server-side in bugzilla.
Well, in order to file reports, abrt has internet connectivity and we could fairly easily determine whether it's obsolete in some way. Some ideas can come from here: http://fedoraproject.org/wiki/End_of_life_SOP such as query koji, pkgdb, etc.
While I think it's useful to also block filing bugs for EOL versions[*], I think the better win will come from abrt actually telling users "you're crashing, and we can't fix it. you really should upgrade". Just having the bug go to /dev/null when bugzilla refuses to accept it won't really help the problem of users on EOL releases.
[*] We'd need to block filing bugs into a specific version, but that can't be done in bugzilla code, only components/products can be blocked AFAIK.
(In reply to comment #2)
> Well, in order to file reports, abrt has internet connectivity and we could
> fairly easily determine whether it's obsolete in some way. Some ideas can come
> from here: http://fedoraproject.org/wiki/End_of_life_SOP such as query koji,
> pkgdb, etc.
- asking one of those sounds like a way to go, but users can still use the webui to fill the bugs for EOLed Fedora, which shouldn't be allowed
> While I think it's useful to also block filing bugs for EOL versions[*], I
> think the better win will come from abrt actually telling users "you're
> crashing, and we can't fix it. you really should upgrade".
- this message can be returned from the bz server when it refuses to create a bug for EOLed release and ABRT would just show it..
> [*] We'd need to block filing bugs into a specific version, but that can't be
> done in bugzilla code, only components/products can be blocked AFAIK.
- well, I don't know the bz code, but blocking EOLed versions doesn't seem like a very difficult thing to implement and even if we can implement it on client(ABRT) side, I still think this should be also implemented on the server side
- what's the point in fixing one client (ABRT) when there are many other clients using bugzilla xmlrpc which would still be able to create a bug for EOLed version?
Jiri, I already agreed we should also fix this in bugzilla. I'm not sure why you think I'm arguing against it. I am saying that abrt should specifically handle it regardless of what bugzilla does.
(In reply to comment #4)
> Jiri, I already agreed we should also fix this in bugzilla. I'm not sure why
> you think I'm arguing against it. I am saying that abrt should specifically
> handle it regardless of what bugzilla does.
Well, that's the problem of this not-in-person and not realtime communication ;)
We actually plan to implement improve bugzilla plugin to talk with koji/bodhi so when we will do that we can also add the check for the EOLed release.
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Reassigning to Rawhide.
Fedora Package Database contains collections. A collection corresponds to one Fedora release. We can read status (EOL or other) there.
For example, Fedora 10:
There is a Python library in Fedora which can easily read the data:
client = fedora.client.PackageDB()
collections = client.get_collection_list()
for collection in collections:
print collection["name"], collection["version"], collection["statuscode"]
To understand the meaning of statuscode, see http://bzr.fedorahosted.org/bzr/packagedb/fedora-packagedb-stable/annotate/head%3A/pkgdb.sql
Currently the mapping from the statuscode integer to a meaningful symbol is as follows. We are probably only interested in EOL == 9.
STATUS_CODES = [ "INVALID_STATUS_CODE",
*** This bug has been marked as a duplicate of bug 681385 ***