On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo) <marcus.m...@wtnet.de> wrote: > 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. >
It can be useful in some cases. If you can identify the last version that did not have the defect, and the first version that did have the defect, then you can narrow down the range of commits that could have caused the bug. Unfortunately I don't see an admin-accessible way to change the field type. In theory someone could work with Infra to get direct DB access and create a new multi-value field and then write some SQL to migrate the old values into the multi-value schema. But I'm not sure that would have much more value than noting these facts in a comment field. In terms of workflow, searching for all confirmed bugs that have not been tested with at least 3.4.0 is useful. It gives us a list of bugs that we should re-test. But I'm not sure why I would search for bugs that were confirmed in a specific old version like 3.4.0. -Rob > 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: 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
