Now that 10.04 has reached end of life...

[Thomas Ward]

Hello!

On 05/17/2015 04:24 PM, Hans Joachim Desserud wrote:
> ... I also found two categories of bugs I didn't know how to deal
> with, so I thought I'd check with others.
>
> 1. Bugs which are targeted to the lucid series [1]. These are usually
> fixed in a newer release but targeted to lucid and/or other releases
> for SRU purposes. If I remember correctly, somone had a script which
> would go through all bugs targeted to a particular release and close
> them with a message explaining the release had reached EOL. I think
> this was run the last time a release reached EOL. Should this be a
> regular thing, and the script re-run for lucid?
>
> (Note, I am talking about bugs _targeted_ towards a release, not
> tagged with one. The tagged ones might still be perfectly reproducible
> in newer releases, so I understand that we can't simply close them
> without investigating further.)
Lucid would be "Won't Fix" if it's a series-targeted bug (not a tag).  A
comment that Lucid is EOL can go with it, and you should make a note in
the response that if it is reproduced in later releases to make a note
as such in the bug.

Lucid only went EOL recently, and I know a series of bugs were
autoclosed.  Others can go through and close these kinds of bugs without
incident I believe.
>
> 2. The second case I found was bugs where I couldn't check if the bug
> persisted because the package had been removed from newer releases of
> Ubuntu. Meaning that once 10.04 reached EOL, there was no longer any
> supported Ubuntu release where package was available. As an example,
> see for instance bug 565110 [2]. How does one proceed with bugs like
> this?
>
> Since it no longer exists in Ubuntu, I doubt these issues will be
> fixed, unless they are addressed upstream or repackaged in Ubuntu.
> Which is a bit sad, but I that also means they are padding out the
> list of open bugs, making it harder to find actual issues. I checked
> to see if there were any default response for this kind of situation,
> but failed to find any. I guess a combination of [3] and [4] might
> make sense, but I'm not sure on how to phrase it.
Tricky, but if the package doesn't exist, you still close the bug as
"Won't Fix" for Lucid.  We can close it as such because it doesn't exist
in later releases.  If the bug has a Lucid and a non-Lucid target, then
I believe that "Won't Fix" for the Lucid target and "Invalid" for later
release targets since the package was removed from those releases is a
proper course of action.  However, in these cases you should comment as
such with these changes, like with the previous bug case of "Won't Fix"
with the only difference being that you explain that the package is no
longer present in later releases.  (Although you don't necessarily have
to do this if the package is removed from later releases, given the
package isn't present.
>
> [1] https://bugs.launchpad.net/ubuntu/lucid/+bugs
> [2] https://bugs.launchpad.net/ubuntu/+source/hanzim/+bug/565110
> [3] https://wiki.ubuntu.com/Bugs/Responses#Old_untouched_bugs
> [4]
> https://wiki.ubuntu.com/Bugs/Responses#Packages_not_provided_by_Ubuntu
>

The problem here is the permissions for bug statuses.  The "Won't Fix"
status and the "Triaged" status can only be set by users/bots in the Bug
Control group.  I had planned on the first of June to look through bugs
still targeted against Lucid, and run a script I developed that uses the
API of Launchpad to close those bugs (I did this for Karmic bugs a while
ago) and comment why that "Won't Fix" status was set.  However, that'd
only hit bugs that are targeted against the Lucid series, not bugs that
aren't specifically in that target series which are against Lucid.



Thomas