Issue 123063 (TooLimitVersRange) - Range in all version related selectors too limited
Summary: Range in all version related selectors too limited
Alias: TooLimitVersRange
Product: Infrastructure
Classification: Infrastructure
Component: Bugzilla (show other issues)
Version: current
Hardware: All All
: P3 Major (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2013-08-19 05:04 UTC by Rainer Bielefeld
Modified: 2014-05-27 05:17 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: Easy


Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2013-08-19 05:04:48 UTC
Currently choice in all selectors is very limited, what more or less makes information in these selectors valueless.

If you do research in an area with similar Bug Reports, what might be related, some even Duplicates, and some independent bugs, information 
A) when a bug has been observed first ("Version") 
B) with what latest versions it has been reproduced ("Latest Confirmation on")
C) with what version the bug is no longer reproducible ("Target Milestone")
are very important distinctive features, what additionally are required to 
do reliable queries. Additionally info in these selectors help to decide whether a bug is expected to be reproducible in reporter's version.

Example: "Bug 106204 - AutoFilter on a sheet disappears if AutoFilter applied on other sheet"
We still have a bunch of Auto Filter problems, some of them might have common roots, some not, who can now.

B) For Bug 106204 I found that it was reproducible with versions available for me until AOO 3.4.1. But the only Version offered in "Latest Confirmation on" 4.0.0

C) I can't see that bug any longer with 4.0.0 and would like to select TM 4.0.0, but the only available is 4.0.1

So currently it's impossible to select useful correct data.

Currently my concerns might look like nitpicking, but in 2 years, when AOO still will be with some Autofilter problems, such info will be missing to get some order into the related bugs.

Please simply keep available all published AOO versions for all these pickers,  and additionally "pre 3.4.0" for bugs inherited from OOo times and latest Trunk and Branch Builds (4.01., 4.1.0).
Comment 1 jan iversen 2013-08-19 05:16:47 UTC
I agree with the point of view. I am however not sure if the average user can use these fields correctly. 

I would like to suggest that a wiki page is created that shortly explains how to use the different fields, and then if possible link to it from this page in BZ.

jan I.
Comment 2 Edwin Sharp 2013-08-19 05:53:06 UTC
I hope in 2 years time there will be no more auto-filter problems! :)
Comment 3 Rob Weir 2013-08-19 12:18:37 UTC
IMHO, if bug is not reproducible in 4.0.0 then just mark as Resolved/Fixed and move on.   Is there any good reason to spend additional time on it indicating that you tested on 3.4.1 or setting a target milestone of 4.0.0, etc?  Is that info valuable for anything?  If it is fixed then it is not worth spending more time on it.  My opinion at least.

Also, the practical problem we had with offering more choices on these fields is that users would use them incorrectly.

Finally, we want to encourage users and QA to test with the most recent version.  It is not very useful to test a bug with 3.4.1.  Either the bug is found there or it isn't.  If it is found in 3.4.1 then you still must retest with 4.0.0.  So why not just focus on testing with 4.0.0?
Comment 4 Edwin Sharp 2013-08-19 13:06:02 UTC
(In reply to Rob Weir from comment #3)
> Finally, we want to encourage users and QA to test with the most recent
> version.  It is not very useful to test a bug with 3.4.1.  Either the bug is
> found there or it isn't.  If it is found in 3.4.1 then you still must retest
> with 4.0.0.  So why not just focus on testing with 4.0.0?

Unfortunately, 4.0 is not as good as 3.4.1.
Quite a few bug reports declared they were rolling back to 3.4.1.
Test with most recent? 
Only when we have continual improvement (like in ISO 9001), but this is not the case in reality.
Comment 5 Rainer Bielefeld 2013-08-19 13:26:29 UTC
(In reply to Rob Weir from comment #3)
Hi Rob,
That's a complete misunderstandig of the function of the version related fields. Following your arguments we could simply drop them.

But these fields have an important function to find relations between bugs and code commits, especially for handling of regressions. 

Some Examples:

If I have 2 similar looking bugs (may be Calc-Conditional-formatting does not work in a particular way), tests show that 
- problem 1 of Bug Report 1 with sampledocument1  starts with 3.3.0 
- problem 2 of Bug Report 2 with sampledocument2  starts with 3.4.1
So this difference indicates that although the observed effects are the same, the bugs seem to have different roots

In regressions developer should try to find out what code commit caused the problem, and why it has been introduced. Without that knowledge his changes to solve the current problem might cause a new (old) problem.

Target Milestone
If it's not only used as a goal, but also to indicate for what Version a bug really has become fixed, the function is similar to Version: If there are bug reports concerning similar looking effects, but one is no longer reproducible with 3.4.1 (=TM), a second one no longer with 4.0.0 (but still), and I 

Latest Confirmation on
If I do a Bug Report cleanup, again for the Calc-Conditional-formatting, I try to find DUPs to the bug I have handled few minutes ago. If I found out that the Bug has been fixed for 3.4.1, I can exclude Bugs with "latest confirmed for 4.0), those ones can not be DUPs of a bug  fixed for 3.4.1.

And so on.

These are some of the query tricks what can be used to work more efficient with Bugzilla. We should not configure the tools for the lusers, but for the experts. Although, of course, I see the problem with wrong handling selectors. But that problem should be used by adjusting permissions, not by limiting contents of selectors to useless remainders
Comment 6 Oliver-Rainer Wittmann 2013-08-21 14:57:25 UTC
I somehow agree with Rainer.

My scenario which would benefit from the existence of a value like 'pre 3.4.0' for field Version:
In the last days I reviewed certain defects reported on version 4.0.0 - value of field Version = 4.0.0. My investigation reveals for some of them already occur in AOO 3.4.0, but not in OOo 3.3.0. Thus, I changed value of field Version to 3.4.0 while setting Latest Confirmation on to 4.0.0. Some are reproducible in OOo 3.3.0 as well. Here, I also changed the value of field Version to 3.4.0 loosing the possibility to distinguish between these issues.

My opinion of field Target Milestone:
This field should only be set, when it is 100% clear that the issue is solved in a certain version - as it is more or less documented. To request a solution for a certain version we are using our flags. Thus, may be it makes sense to restrict the access to this field to the corresponding group.
And yes - as Rainer said - having values for former releases would enable us to document that a submitted issue from a user using a former version has been fixed in an already available release. This is not really critical, but would have a documentary purpose.

I am not sure, if we would need values for former released versions for field Latest Confirmation on, when we would have values for former released versions for field Target Milestone. For solved issues we have Latest Confirmation on == Target Milestone - 1
Comment 7 Rainer Bielefeld 2013-10-03 07:15:46 UTC
If BZ adims think that number of available versions might confuse unexperienced users (I think that would be a real problem with the VERSION selector) they should find a way to hide those selectors for that user group or limit the number of visible versions for those users. But destroying the expert's tool is not an appropriate solution.
Comment 8 Rainer Bielefeld 2013-10-06 05:48:44 UTC
I'm going to add all Bug reports with inappropriate version information here to "See Also" so that it will be possible to repair that later. 
Lacking sense to see the problem is really daunting.

I add Lacking sense to see the problem is really daunting.

I add Bug 119006: TM 4.0.0 is not plausible for a problem reported with the same version and also (possibly) 4.0.1
Comment 9 Rob Weir 2013-10-06 15:23:01 UTC
Rainer, the Target Milestone field is not for indicating what release a defect was fixed it.  That field is for a developer to indicate when they are planning on fixing a bug.  For example, some bugs might be targeted to a 4.1 while others are targeted to 4.0.1.  But developers don't always deliver fixes per their original intentions.  For example, I recently cleared the milestone field for a bunch of unfixed issues that had target milestone set to 4.0.0 and 4.0.1.  

If you want a "fixed version" field added to BZ then please make a proposal for this on the dev list.  In fact, if you want any non-routine changes to the bug tracking process currently in use in the project please make a proposal on the dev list.  This is not something that 3 or 4 people are going to change in side discussion on a BZ issue.
Comment 10 Rainer Bielefeld 2013-10-06 16:59:36 UTC
Hi Rob,
I know how Target Milestone is used, and that's completely ok, no appeal from my side.

But we urgently need reliable ("query proof") TM information for FIXED bugs, what allows some sorting of possible DUPs, and together with "VERSION" and "Latest Confirmation" QA staff with no (like me) or only few C code knowledge this version info is a very powerful and important indicator for relations between bugs.

So the simple request here is not to hinder QA staff by breaking tools, please reenable all AOO versions including the "Pre-3.4.0" for general use in all version selectors. Some few wrong use of the selectors by unexperienced users is much more tolerable than a (more or less) complete cut-off.
Comment 11 Rob Weir 2013-10-06 18:29:33 UTC
Rainer,that's not my decision.  Make a proposal on the dev list and if there is consensus then I will be happy to help.

To be honest I will argue against such a change, but neither my opinion nor yours alone will decide this.
Comment 12 Rainer Bielefeld 2014-05-22 04:55:33 UTC
(In reply to Rob Weir from comment #9)
Your explication is correct for Bugs with A status before fixed and wrong with status FIXED. When the Bug becomes fixed developer inserts the Version with with what the fix will be available. If a bug has becomes fixed without any action for the particular bug (because the fix is integrated in a fix for an other (unknown) bug report or during normal progress of the progress, the one who checks the bugs selects the oldest version for what the bug no longer does exist. This information helps to distinguish bugs with similar symptoms. 
There is no need for an extra field.