[ACTION REQUIRED v3] Retiring packages for F-17

[Michael Schwendt]

On Sat, 28 Jan 2012 09:02:50 -0800, AW (Adam) wrote:

> > The bugzilla account called "Bug Zapper" is a human-being not a script?
> > Unbelievable.
> 
> We run a search to identify the bugs to be closed (it's a stored search
> in Bugzilla), manually weed the list, and then send the list to
> engineering services to do the actual closing.

Who was responsible for these tickets then and has not taken them off the
list? What would have been necessary inside the tickets to get them taken
off the list, if not repeated confirmation and updating of the tickets?
How often is the reporter (or a Cc member) supposed to prevent the ticket
from getting closed? There are comments in reply to the EOL warning, but
no human-being acknowledges them. A few months later, there is another
automated EOL warning, and voila, you've annoyed another user.

> > Examples, and there are more like these:
> 
> There's nothing wrong with any of these examples. The agreed policy of
> the project is that bugs for old releases which aren't updated for new
> releases get closed. Just because you confirmed a bug was valid against
> a release that was current in 2008 does not mean it should still be open
> in 2012. For the bug to stay open it should be re-tested with a
> currently-supported version and updated to that version.

Please don't reply if you didn't even try to understand these examples.
I have verified the issues against a _current_ release and/or the
current development version. After doing that, I've updated the tickets
or reopened them appropriatly. That has not stopped a bug zapper from
keeping them on the list of tickets to close. How 2012 would be relevant
here, is beyond me.

> > Your 'a)' is wishful-thinking. It is true for some bugs
> 
> Then it's not wishful thinking, is it?
> 
> > , but

The "but" was important. Don't truncate quotes like that.
It doesn't make any discussion easier.

> I specifically
> > referred to issues in xmms* packages. 
> 
> You may have used those as examples, but the discussion was about the
> bug retirement policy in general.

Then you have misunderstood it, unfortunately. I'm not against EOL ticket
cleanup procedures in general. I'm against closing tickets repeatedly
after it has been shown that an issue is still present in the current dist
and nobody has proven the opposite. Especially, if a problem is due to a
packaging issue in a specific package (and that has been pointed out
explicitly), a bug zapper could notice that the package has not been
modified (beyond automated rebuilds) and _cannot_ fix the issue.
 
> Then we have a problem with the packager, yes? Not a problem with the
> bug retirement process.

Both, obviously.