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 ?
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
