[Libreoffice-qa] Version field options way too fine grained

V Stuart Foote VStuart.Foote at utsa.edu
Fri Mar 14 07:56:55 PDT 2014


Not so sure, because it goes the other way as well.  

When attempting to triage a bug, having the correct release --or better the commit information to exactly reproduce the issue as reported, and work backward to point of origin-- the granular field remains very helpful.

So perhaps  it is not the best for data query and monitoring, but still very helpful for isolating the issues.  I'd say leave it as is and improve scope of your query logic.


From: libreoffice-qa-bounces at lists.freedesktop.org <libreoffice-qa-bounces at lists.freedesktop.org> on behalf of Kohei Yoshida <libreoffice at kohei.us>
Sent: Friday, March 14, 2014 8:58 AM
To: Libreoffice QA List
Subject: [Libreoffice-qa] Version field options way too fine grained

Hi there,

Another thing I'd like to inquire about is that currently we have way
too fine-grained version field options it's becoming increasingly
difficult to query for "give me all bugs for 4.2" and similar.  For
instance, even for the 4.2 branch we have,

and so on. We have way too many to list all.  4.1 is in a similar

I have my saved query and try to select all relevant versions but it's
prone to errors.  Today I just discovered a regression that I didn't see
before because its version field was set to which I
didn't include in my saved search.

IMO we should only have 4.0, 4.1, 4.2 etc as version.  All these too
fine grained version numbers only serve to make bugs discoverable.

What do you guys think about this?


More information about the Libreoffice-qa mailing list