[Libreoffice-qa] After EOL has been reached...

Joel Madero jmadero.dev at gmail.com
Tue Apr 23 12:26:43 PDT 2013

> ---------- Forwarded message ----------
> From: Robinson Tryon <bishop.robinson at gmail.com>
> To: Petr Mladek <pmladek at suse.cz>
> Cc: LibreOffice-QA <libreoffice-qa at lists.freedesktop.org>
> Date: Tue, 23 Apr 2013 11:34:45 -0400
> Subject: Re: [Libreoffice-qa] After EOL has been reached...
> On Tue, Apr 23, 2013 at 7:30 AM, Petr Mladek <pmladek at suse.cz> wrote:
> > Robinson Tryon píše v Pá 19. 04. 2013 v 17:21 -0400:
> >
> > 6 months sounds fine to me for most of the bugfix releases.
> >
> > Well, I would suggest to leave either the last bugfix release or some
> > generic version, e.g. 3.5, 3.4, 3.3 longer time. We want to keep the
> > version flag on the oldest affected version. It might be handy to have
> > the old version to correctly mark the old bugs that were not reported in
> > time.
> So how about:
> "De-list release in Bugzilla 6 months after EOL, and leave a generic
> X.x version in its place" ?

+1, I think *almost* everyone agrees with this, my suggestion is formal
vote next call and discuss procedure for voting going into the future. I
think endless discussion where there is disagreement that isn't being
solved is useless - a vote solves this. Maybe 1 month period to discuss,
then vote (2 calls worth of time more than enough)

> That also gives us a quick way to query for bugs that were reported
> after EOL, which might be something that we find interesting.


Hi Robinson,
> not good! We will not create complicated wrong rules for things what are
> easy to understand. And whether a Version still is useful for indicating
> where in the history a (newly reported) bug appeared has nothing to do with
> the date of the last build. So already the subject of this thread is
> misleading for this issue.

I disagree....

> LibO-Bugzilla admins will switch old Versions to "inactive" when they see
> that no more (or very few) bugs appear newly in BZ with that version.
> That's the only indicator that counts, that already is in progress, no
> reason for concerns.

Formalizing some procedure isn't a bad thing, saying "we'll do it when it
happens" seems bad. 3.5 would give more than enough info to say "it's been
around a long long time" and going into the future we hope that regressions
are handled quickly so knowing the exact minor version is irrelevant for
our purposes. Furthermore, bibisect would handle regressions all the way
back to 3.6alpha so that solves any issue there.

> I think that there are actually two separate issues here:
> 1) What versions of LO are users *actively* using and against which we
> are seeing bugs reported?
> 2) What is the earliest version of LO in which we reproduce a bug?
> >
> > It seems that 3.4 will reach a status what sill allow to switch inactive
> the
> > non-release versions (see statistics for last half year [1]) soon.
> Of the 4 bugs you list for 3.4,
> 1 was a Bugzilla test by Joel (irrelevant)
> 1 was an AOO bug (!) mistakenly reported in our bugtracker (also
> irrelevant)
> 1 was reported against 4.0, and traced back to 3.4.5 by Rainer (so not
> reported against 3.4)
> 1 was reported by a LO developer with 60+ commits to his name (i.e.
> largely pre-triaged)
> tl;dr: In the last 6 months no ordinary users have reported a bug against
> 3.4.

good points here.....

> Here's a fun Question: Does anyone know off the top of their head how
> many 3.4.x versions we have listed in FDO? I just counted, and it's a
> whopping 22. All for a release that we consider EOL'd over a year ago!
> limiting the list to versions that are still supported does seem like best
plan to simplify things for our users....

The only question I have for admin side is if we inactivate a version, can
QA still set the version to these or is this not possible? It would be nice
if users can't set it but QA team can....if we cannot, then this becomes a
little trickier but not a hurdle that we can't get over.

Bjoern - you mind putting in your two cents also, would be good to hear
your thoughts.


*Joel Madero*
LibreOffice QA Volunteer
jmadero.dev at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice-qa/attachments/20130423/0ab04b10/attachment.html>

More information about the Libreoffice-qa mailing list