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 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 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. > > 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: qa-unsubscr...@openoffice.apache.org > For additional commands, e-mail: qa-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
