Bugzilla should refuse to report bug against obsoleted products. Either using XMLRPC or web interface. +++ This bug was initially created as a clone of Bug #684364 +++ 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. --- Additional comment from jmoskovc on 2011-03-13 05:38:56 EDT --- 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. --- Additional comment from caillon on 2011-03-13 17:21:15 EDT --- 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. --- Additional comment from jmoskovc on 2011-03-24 12:15:18 EDT --- (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? --- Additional comment from caillon on 2011-03-24 12:57:34 EDT --- 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. --- Additional comment from jmoskovc on 2011-03-24 17:34:41 EDT --- (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. --- Additional comment from triage.org on 2011-05-30 07:01:07 EDT --- 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from kklic on 2011-06-01 05:35:08 EDT --- 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: Id: 19 Name: Fedora Version: 10 Status: EOL Fedora 14: Id: 25 Name: Fedora Version: 14 Status: ACTIVE There is a Python library in Fedora which can easily read the data: import fedora.client client = fedora.client.PackageDB() collections = client.get_collection_list() for collection in collections: print collection[0]["name"], collection[0]["version"], collection[0]["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", "ACTIVE", "ADDED", "APPROVED", "AWAITING_BRANCH", "AWAITING_DEVELOPMENT", "AWAITING_QA", "AWAITING_PUBLISH", "AWAITING_REVIEW", "EOL", "DENIED", "MAINTENANCE", "MODIFIED", "OBSOLETE", "ORPHANED", "OWNED", "REJECTED", "REMOVED", "UNDER_DEVELOPMENT", "UNDER_REVIEW", "DEPRECATED" ] --- Additional comment from jmoskovc on 2011-10-10 10:34:18 EDT --- *** This bug has been marked as a duplicate of bug 681385 ***
Red Hat Bugzilla does not allow reporting against obsolete products. However, what you are reporting is relating to the version number (In this case, version '12' of the 'Fedora' product). The Fedora product is not obsolete :) Bugzilla does not have a concept of an 'obsolete' version. The best solution that I can think of is having a new product for each version. This is what we do for most RHEL products and all JBoss products in Bugzilla. For example, we have 'Red Hat Enterprise Linux 5' and 'Red Hat Enterprise Linux 6'. ... -- simon
(In reply to comment #1) > > Bugzilla does not have a concept of an 'obsolete' version. IIRC, this was discussed upstream at one point. I'm not sure what (if anything) came out of it. > The best solution that I can think of is having a new product for each > version. You could limit yourself to two products, 'Fedora' and 'Fedora (EOL-ed)'. Bugs could be moved from the former to the latter when a version of Fedora is EOL-ed (and, of course, the second product would have bug-entry disabled).