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

Robinson Tryon bishop.robinson at gmail.com
Fri Apr 26 07:56:21 PDT 2013

On Fri, Apr 26, 2013 at 5:24 AM, Bjoern Michaelsen
<bjoern.michaelsen at canonical.com> wrote:
> On Fri, Apr 26, 2013 at 09:47:28AM +0200, Jean-Baptiste Faure wrote:
>> Le 19/04/2013 23:21, Robinson Tryon a écrit :
>> > AGREED: We de-list versions in Bugzilla 6 months after the release has
>> > been EOLed
>> I do not see any rationale for that.
>> What I suggest is to remove all RC and beta version from BugZilla as
>> soon as the corresponding final version has been published.
> Hmm, sounds like a good idea too.


I think we need to be even more aggressive in de-listing versions, but
if this is a cut we can all agree on, let's start there :-)

> but  If someone triages it even further (e.g. a
> bug was not there in 3.6.2 rc1 but is in the final version), a comment in the
> bug might suffice.

This kind of scenario is one of the reasons I was interested in
implementing my "Repro Table". The current version drop-down is both
too long and not granular enough to visually indicate the NOREPRO in
3.6.2 rc1 and the REPRO in 3.6.2 release. The Repro Table could
display that information very clearly, but I am digressing a bit :-)

> Note that the reduction of the numbers of versions to select from is valuable
> in itself. I find myself being annoyed by scrolling through that long list in a
> small box, and imagine it is even more irritating to e.g. a first time bug reporter.

Here are some numbers for reference. I might add that since the
beginning of this thread, (I believe) several old versions have
already been de-listed from Bugzilla, so I feel like we're making
progress already!

The version drop-down in Bugzilla currently contains some 86 different
entries (see Appendix #1). Here's a breakdown by minor version:

Minor Version - Total, non-Release

3.3 - 6, 1
3.4 - 22, 15
3.5 - 23, 15
3.6 - 19, 12
4.0 - 12, 9
4.1 - 1, 1

Other - 3, 1

If we were to de-list the non-release stuff from 3.3 - 3.5, that would
shorten things by a good 31 entries, but the list would still be
pretty long.

If we were to remove all non-Release alpha/beta/RC items from every
version (even open ones) , that would help a bit and pare the list
down to 32 items, but remember that we'd still be growing the list by
7-8 new entries for each new minor version. That means that just by
the end of 2013, we'd add another 10 entries to be at 42.

One of the reasons I like the idea of de-listing all of the versions
for a minor release and replacing them with just an X.x (e.g. "3.5")
is that it would slash the number of versions that are in EOL. If we
did that for the table above, we'd be down to 38. If we then removed
out-of-date non-Releases for 3.6. and 4.0, we'd cut the list to a
svelte 17:

(See in Summary)

3.5 release release release release release release release release release release rc Master


I think the shorter list is *much* more manageable for our users in a
drop-down. I do agree that it shortens the list that can be selected
when hunting-down the particular version that introduced the bug, but
I think that the version field isn't ultimately the best tool for
those purposes -- something like the Repro Table is a much better bet.


Appendix 1:

(See in Summary)

3.3.0 Beta2
3.3.0 release
3.3.1 release
3.3.2 release
3.3.3 release
3.3.4 release

3.4.0 Beta1
3.4.0 Beta2
3.4.0 Beta3
3.4.0 Beta4
3.4.0 Beta5
3.4.0 RC1
3.4.0 release
3.4.1 RC1
3.4.1 RC2
3.4.1 release
3.4.2 RC1
3.4.2 RC2
3.4.2 release
3.4.3 RC1
3.4.3 release
3.4.4 RC1
3.4.4 release
3.4.5 RC1
3.4.5 release
3.4.6 RC1
3.4.6 release
3.4 Daily

3.5.0 Beta0
3.5.0 Beta1
3.5.0 Beta2
3.5.0 Beta3
3.5.0 RC1
3.5.0 RC2
3.5.0 release
3.5.1 RC1
3.5.1 release
3.5.2 RC1
3.5.2 release
3.5.3 RC1
3.5.3 release
3.5.4 RC1
3.5.4 release rc rc release rc release rc release
3.5 Daily rc rc rc release rc release rc release rc release rc release release rc release Master rc rc release rc release rc release rc Master

Master old  -3.6


More information about the Libreoffice-qa mailing list