@Kohei, 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. Stuart ________________________________________ From: libreoffice-qa-boun...@lists.freedesktop.org <libreoffice-qa-boun...@lists.freedesktop.org> on behalf of Kohei Yoshida <libreoff...@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 4.2.0.0alpha0+Master, 4.2.0.0alpha1 4.2.0.0beta1 ... 4.2.0.1rc 4.2.0.2rc ... and so on. We have way too many to list all. 4.1 is in a similar situation. 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 4.2.0.0alpha0+Master 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? Kohei _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/