Isn't it time for v4 ?
Alex
----- Original Message -----
> From: "Michael Schwendt" <mschwendt@xxxxxxxxx>
> To: devel@xxxxxxxxxxxxxxxxxxxxxxx
> Sent: Tuesday, January 31, 2012 12:38:12 PM
> Subject: Re: [ACTION REQUIRED v3] Retiring packages for F-17
>
> 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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
