Am 08/05/2013 06:31 PM, schrieb Rob Weir:
On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)<marcus.m...@wtnet.de> wrote:
Am 08/05/2013 05:47 PM, schrieb janI:
On 5 August 2013 17:38, Rob Weir<robw...@apache.org> wrote:
I'd like to update BZ to reflect the next release of AOO.
Version are tracked in three different fields:
Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"
Target Milestone, which currently allows the values "AOO 4.0", "AOO
4.1" and "AOO PleaseHelp"
Last Confirmation on, which currently allows the values "AOO 3.4.0",
"AOO 3.4.1", and "AOO 4.0.0".
I'd like to clean this up a little, as follows:
1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
4.0.0. None of these versions are "end of life" so they should be
allowed for new bug reports.
+1
2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
Are we overloading meaning in this field? If we really need track
issues that need help we should define a keyword for this. So I'm
inclined to delete this milestone version number.
If it's possible to delete the item without to leave gaps in the issues
itself then +1.
3) I'd also like to simplify the versions across the board to be just
"3.4.1", "4.0.0", etc., without the "AOO" prefix.
+1
4) For Last Confirmation On, I'd like to hide values except for 4.0.
We should not be confirming bugs without testing on the most recent
version. Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
confirmation should occur on 4.0.
Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live
version, which we support, all bugs reported there must also be tested
there.
I agree they should also be tested in 4.0, but not only in 4.0.
So we would actually need a double confirmation, 3.4.x and 4.0 ?
Current field is a single-selection drop down. BZ does allow
multiple-selection fields, but I don't see any way to switch the type
of a field once it has been used.
In any case I'm not inviting debate of the process. I appreciate that
You asked for feedback. ;-)
> I appreciate that
some might wish that the QA volunteers spent twice as much time and
tested on twice as many versions of AOO. But changing a BZ field
obviously doesn't cause that to happen. My intent was merely to
I don't wish this. If they do it, they do it on their own. I believe
there is also a way sometimes to trust the user or developer when they
choose 3.4.1 and 4.0.0 as confirmed versions.
update the field to support the purpose the field was added in the
first place, to track the most-recent version of AOO the bug was
confirmed on.
OK, looking at the title of the field then indeed only one version is
possible.
However, I still think there is a value add to have the confirmation
that a bug is occurring in more than just the most recent version.
Marcus
Right, to recognize a regression faster it should be possible to set the
values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for this
field?). Then you can see on the first view that the issue is not a new
thing in 4.0.0 but was already exisiting also in 3.4.1.
5) I'll add a new Target Milestone of "4.0.1" and Version of
"4.0.1-dev" since it is likely that we will have a 4.0.1 release to
address some of the defects that have been reported on 4.0.0.
+1
Then we can separate easily:
- fast fixed for 4.0.1
- general new things for 4.1.0
I'd love to hear your thoughts on this, even if it is just a quick +1.
I'll hold off making any of these changes until this time Thursday.
+1 to all except 4).
I agree with Jan.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
