Bug 684364

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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" ]

*** This bug has been marked as a duplicate of bug 681385 ***