On Mon, 30 Jan 2012 15:33:39 -0800, AW (Adam) wrote:
> On Sun, 2012-01-29 at 22:21 +0100, Michael Schwendt wrote:
>
> > > What's needed to be sure the bug doesn't get closed is for the Version
> > > field to be bumped to a release that's not going EOL. A comment may do
> > > the job, but there's usually hundreds of bugs in the list to be EOLed
> > > and it's usually a single person compiling the EOL list; they don't have
> > > time to inspect _every_ ticket manually (the weeding is more along the
> > > lines of 'look through the summary list for bugs that look like they may
> > > be special cases').
> >
> > qed ;-)
>
> What was demonstrandumed exactly?
That a script is run to process all the tickets with almost no prior
checking by human-beings.
* "a single person compiling the EOL list"
* "they don't have the time to inspect _every_ ticket manually"
* "(the weeding is more along the lines of 'look through the summary list...)"
Well, you haven't commented on what "special cases" are found that way,
and how many, but I consider tickets with a suspicously low id number
special cases that deserve a _close_ look and special treatment. Even more
so for tickets, which have been taken off the EOL process by somebody
at least once.
The two tickets, which I've pointed at, have still been open three years
after they had been filed. It would have been really lame to auto-close
them without prior investigation. If the only goal is aggressive closing
of old/ancient tickets for bugs, which probably aren't relevant anymore,
this topic is a lost cause.
> You say "The process is flawed,
> however, if tickets that get updated appropriately, don't result in a
> higher priority or are not taken off the bug zapper list"; the question
> is what constitutes 'appropriately'. It's very difficult to construct a
> search such that a *comment* that a bug is still valid is considered to
> render it un-EOL-able, while not causing a bunch of false positives.
The updated product version tag in the ticket renders it un-EOL-able
already. As in the two examples I've linked.
_However_, if nothing else happens when next EOL is reached, the packager
hasn't responded, the reporter hasn't responded (perhaps has left disappointed),
no new upstream release has been packaged, possibly no new upstream
release is available even (and a bug has not been squashed by upstream
independently either), that is a special case that asks for special
treatment.
_If_ previously un-EOL'ed tickets pile up (and obviously some of them will
have been un-EOL'ed more than once even!), that requires a different
process. A process where assignee must answer NEEDINFO, or where there
must be an upgraded package %{version} (which *might* fix the bug), or
where any bug triager may only EOL the ticket if posting a rationale.
If that results in a rapidly growing pile of aging tickets, too, because
nobody handles them either, start thinking about calling Houston.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
