You are viewing a plain text version of this content. The canonical link for it is here.
Posted to qa@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2013/08/05 17:38:34 UTC
Updating BZ versions for next releases
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.
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.
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.
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.
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.
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.
Regards,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Steve Ahlers <sa...@yahoo.com>.
1+ all
Steve
Sent from my iPad
On Aug 5, 2013, at 8:38 AM, Rob Weir <ro...@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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Regards,
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
RE: Updating BZ versions for next releases
Posted by V Stuart Foote <VS...@utsa.edu>.
All reasonable changes that should improve the QA process using BZ,
especially the "last confirmed on" 4.0.0--just will need to be kept up going forward.
My +1
ps.s thanks for asking this time ;-)
p.p.s a special CC for you Rainer so you are aware, here is the thread link in Nabble
http://openoffice.2283327.n4.nabble.com/Updating-BZ-versions-for-next-releases-tp4649357.html
________________________________________
From: Rob Weir [robweir@apache.org]
Sent: Monday, August 05, 2013 10:38 AM
...
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.
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.
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.
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.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rainer Bielefeld <ra...@bielefeldundbuss.de>.
Rob Weir schrieb:
Hi Rob,
> 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.
I agree.
An additional hint: for me the Version is an important distinguishing
mark. Of course the exact version of appearance can be mentioned in a
comment, but that is not very clear and can not be used for reliable
queries. So for me selectable versions like 3.3.x or similar to narrow
down version of appearance would have some benefit, and may be also for
developers it might be useful to have easy access to reliable version
info, what might ease to find the code and commit causing the problem.
But of course, such versions only are useful if many users use them that
way.
> 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.
+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
Discharging that ballast also eases use of regular expressions in queries
> 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.
+1
If someone can confirm a bug with 3.4.1, but no longer with 4.0, he
should close that bug, or ask for help, but I can't see any benefit for
a new entry "Last confirmed with 3.4." or so.
> 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.
Sounds plausible.
Best Regards
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Updating BZ versions for next releases
Posted by V Stuart Foote <VS...@utsa.edu>.
All reasonable changes that should improve the QA process using BZ,
especially the "last confirmed on" 4.0.0--just will need to be kept up going forward.
My +1
ps.s thanks for asking this time ;-)
p.p.s a special CC for you Rainer so you are aware, here is the thread link in Nabble
http://openoffice.2283327.n4.nabble.com/Updating-BZ-versions-for-next-releases-tp4649357.html
________________________________________
From: Rob Weir [robweir@apache.org]
Sent: Monday, August 05, 2013 10:38 AM
...
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.
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.
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.
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.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/05/2013 06:51 PM, schrieb Rob Weir:
> On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 08/05/2013 06:31 PM, schrieb Rob Weir:
>>
>>> On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)<ma...@wtnet.de>
>>> wrote:
>>>>
>>>> Am 08/05/2013 05:47 PM, schrieb janI:
>>>>
>>>>> On 5 August 2013 17:38, Rob Weir<ro...@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.
OK, then this discussion can end here if we have a technical limit.
> 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.
I don't talked about searching for old bugs or restesting them. Just
about the possibilitiy to give a fast and visible indication if it's a
new bug or a regression. That's all.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/05/2013 06:51 PM, schrieb Rob Weir:
> On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 08/05/2013 06:31 PM, schrieb Rob Weir:
>>
>>> On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)<ma...@wtnet.de>
>>> wrote:
>>>>
>>>> Am 08/05/2013 05:47 PM, schrieb janI:
>>>>
>>>>> On 5 August 2013 17:38, Rob Weir<ro...@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.
OK, then this discussion can end here if we have a technical limit.
> 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.
I don't talked about searching for old bugs or restesting them. Just
about the possibilitiy to give a fast and visible indication if it's a
new bug or a regression. That's all.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 08/05/2013 06:31 PM, schrieb Rob Weir:
>
>> On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)<ma...@wtnet.de>
>> wrote:
>>>
>>> Am 08/05/2013 05:47 PM, schrieb janI:
>>>
>>>> On 5 August 2013 17:38, Rob Weir<ro...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 08/05/2013 06:31 PM, schrieb Rob Weir:
>
>> On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)<ma...@wtnet.de>
>> wrote:
>>>
>>> Am 08/05/2013 05:47 PM, schrieb janI:
>>>
>>>> On 5 August 2013 17:38, Rob Weir<ro...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/05/2013 06:31 PM, schrieb Rob Weir:
> On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 08/05/2013 05:47 PM, schrieb janI:
>>
>>> On 5 August 2013 17:38, Rob Weir<ro...@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: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/05/2013 06:31 PM, schrieb Rob Weir:
> On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 08/05/2013 05:47 PM, schrieb janI:
>>
>>> On 5 August 2013 17:38, Rob Weir<ro...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 08/05/2013 05:47 PM, schrieb janI:
>
>> On 5 August 2013 17:38, Rob Weir<ro...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 08/05/2013 05:47 PM, schrieb janI:
>
>> On 5 August 2013 17:38, Rob Weir<ro...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/05/2013 05:47 PM, schrieb janI:
> On 5 August 2013 17:38, Rob Weir<ro...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 5, 2013 at 11:47 AM, janI <ja...@apache.org> wrote:
> On 5 August 2013 17:38, Rob Weir <ro...@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.
>>
>> 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.
>>
>> 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.
>>
>> 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 ?
>
It is a relatively new field, a custom field we added to BZ after
3.4.1. The intent was to go through the old defect reports, the ones
that were reported against 3.3.0 and earlier, and retest them with
3.4.1 to see if they still existed. In many cases the bugs no longer
existed. So the "Last Confirmed On" field was there to record the
most-recent version of AOO that exhibited the bug.
We don't currently have a structured way of tracking a list of all
versions where the bug exists. In general I don't think the QA
volunteers are going back and retesting bugs with earlier versions.
It is more the opposite -- retesting old bugs with the most recent
version of AOO.
>
>>
>> 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.
>>
>> 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).
>
> rgds
> jan I.
>
>
>>
>> Regards,
>>
>> -Rob
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Aug 5, 2013 at 8:47 AM, janI <ja...@apache.org> wrote:
> On 5 August 2013 17:38, Rob Weir <ro...@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.
> >
> > 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.
> >
> > 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.
> >
> > 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 ?
>
>
> >
> > 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.
> >
> > 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).
>
> rgds
> jan I.
>
+1, same as Jan's comments
>
>
> >
> > Regards,
> >
> > -Rob
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
--
-------------------------------------------------------------------------------------------------
MzK
Success is falling nine times and getting up ten."
-- Jon Bon Jovi
Re: Updating BZ versions for next releases
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/05/2013 05:47 PM, schrieb janI:
> On 5 August 2013 17:38, Rob Weir<ro...@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: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 5, 2013 at 11:47 AM, janI <ja...@apache.org> wrote:
> On 5 August 2013 17:38, Rob Weir <ro...@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.
>>
>> 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.
>>
>> 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.
>>
>> 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 ?
>
It is a relatively new field, a custom field we added to BZ after
3.4.1. The intent was to go through the old defect reports, the ones
that were reported against 3.3.0 and earlier, and retest them with
3.4.1 to see if they still existed. In many cases the bugs no longer
existed. So the "Last Confirmed On" field was there to record the
most-recent version of AOO that exhibited the bug.
We don't currently have a structured way of tracking a list of all
versions where the bug exists. In general I don't think the QA
volunteers are going back and retesting bugs with earlier versions.
It is more the opposite -- retesting old bugs with the most recent
version of AOO.
>
>>
>> 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.
>>
>> 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).
>
> rgds
> jan I.
>
>
>>
>> Regards,
>>
>> -Rob
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by janI <ja...@apache.org>.
On 5 August 2013 17:38, Rob Weir <ro...@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.
>
> 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.
>
> 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.
>
> 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 ?
>
> 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.
>
> 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).
rgds
jan I.
>
> Regards,
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Updating BZ versions for next releases
Posted by janI <ja...@apache.org>.
On 5 August 2013 17:38, Rob Weir <ro...@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.
>
> 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.
>
> 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.
>
> 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 ?
>
> 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.
>
> 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).
rgds
jan I.
>
> Regards,
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Updating BZ versions for next releases
Posted by Rainer Bielefeld <ra...@bielefeldundbuss.de>.
Rob Weir schrieb:
Hi Rob,
> 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.
I agree.
An additional hint: for me the Version is an important distinguishing
mark. Of course the exact version of appearance can be mentioned in a
comment, but that is not very clear and can not be used for reliable
queries. So for me selectable versions like 3.3.x or similar to narrow
down version of appearance would have some benefit, and may be also for
developers it might be useful to have easy access to reliable version
info, what might ease to find the code and commit causing the problem.
But of course, such versions only are useful if many users use them that
way.
> 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.
+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
Discharging that ballast also eases use of regular expressions in queries
> 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.
+1
If someone can confirm a bug with 3.4.1, but no longer with 4.0, he
should close that bug, or ask for help, but I can't see any benefit for
a new entry "Last confirmed with 3.4." or so.
> 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.
Sounds plausible.
Best Regards
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/05/2013 06:26 PM, schrieb Rob Weir:
> On Mon, Aug 5, 2013 at 12:06 PM, Andrea Pescetti<pe...@apache.org> wrote:
>> On 05/08/2013 Rob Weir wrote:
>>>
>>> I'd love to hear your thoughts on this, even if it is just a quick +1.
>>
>>
>> Here's my quick +1, with a question: when I report a bug (typically a small
>> regression) that I would like to see fixed in the possible 4.0.1 release,
>> shall I already set the Target to 4.0.1? In ancient times this was left to
>> the developer who had accepted the bug, but we are now less strict in
>> Bugzilla usage. And setting the target to 4.0.1 would help in evaluating
>> if/when we need a 4.0.1.
>>
>
> That question probably deserves its own thread. IMHO we need to
> decide what a 4.0.1 is:
>
> 1) We might want to have it contain fixes for only the most urgent
> bugs. We could include new translations that are available as well.
> If we make that restriction then the QA impact is less. We don't need
> to do a complete regression test pass. If we did that then we could
> use the "release blocker" field to track these issues. We'd only fix
> issues in 4.0.1 that have been discussed as release blockers.
>
> 2) Or we could open 4.0.1 up to all changes, in which case new bugs
> can be introduced anywhere, possible translation impact, etc.
>
> Personally I think 4.0.1 should be more like #1 -- strictly limited to
> specific bug fixes. We then use 4.1 (the trunk) for non-urgent
> fixes.
OK, before I put in my 2 cents also here. Rob or Andrea, will you open a
new thread?
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/05/2013 06:26 PM, schrieb Rob Weir:
> On Mon, Aug 5, 2013 at 12:06 PM, Andrea Pescetti<pe...@apache.org> wrote:
>> On 05/08/2013 Rob Weir wrote:
>>>
>>> I'd love to hear your thoughts on this, even if it is just a quick +1.
>>
>>
>> Here's my quick +1, with a question: when I report a bug (typically a small
>> regression) that I would like to see fixed in the possible 4.0.1 release,
>> shall I already set the Target to 4.0.1? In ancient times this was left to
>> the developer who had accepted the bug, but we are now less strict in
>> Bugzilla usage. And setting the target to 4.0.1 would help in evaluating
>> if/when we need a 4.0.1.
>>
>
> That question probably deserves its own thread. IMHO we need to
> decide what a 4.0.1 is:
>
> 1) We might want to have it contain fixes for only the most urgent
> bugs. We could include new translations that are available as well.
> If we make that restriction then the QA impact is less. We don't need
> to do a complete regression test pass. If we did that then we could
> use the "release blocker" field to track these issues. We'd only fix
> issues in 4.0.1 that have been discussed as release blockers.
>
> 2) Or we could open 4.0.1 up to all changes, in which case new bugs
> can be introduced anywhere, possible translation impact, etc.
>
> Personally I think 4.0.1 should be more like #1 -- strictly limited to
> specific bug fixes. We then use 4.1 (the trunk) for non-urgent
> fixes.
OK, before I put in my 2 cents also here. Rob or Andrea, will you open a
new thread?
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 5, 2013 at 12:06 PM, Andrea Pescetti <pe...@apache.org> wrote:
> On 05/08/2013 Rob Weir wrote:
>>
>> I'd love to hear your thoughts on this, even if it is just a quick +1.
>
>
> Here's my quick +1, with a question: when I report a bug (typically a small
> regression) that I would like to see fixed in the possible 4.0.1 release,
> shall I already set the Target to 4.0.1? In ancient times this was left to
> the developer who had accepted the bug, but we are now less strict in
> Bugzilla usage. And setting the target to 4.0.1 would help in evaluating
> if/when we need a 4.0.1.
>
That question probably deserves its own thread. IMHO we need to
decide what a 4.0.1 is:
1) We might want to have it contain fixes for only the most urgent
bugs. We could include new translations that are available as well.
If we make that restriction then the QA impact is less. We don't need
to do a complete regression test pass. If we did that then we could
use the "release blocker" field to track these issues. We'd only fix
issues in 4.0.1 that have been discussed as release blockers.
2) Or we could open 4.0.1 up to all changes, in which case new bugs
can be introduced anywhere, possible translation impact, etc.
Personally I think 4.0.1 should be more like #1 -- strictly limited to
specific bug fixes. We then use 4.1 (the trunk) for non-urgent
fixes.
-Rob
> Regards,
> Andrea.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 5, 2013 at 12:06 PM, Andrea Pescetti <pe...@apache.org> wrote:
> On 05/08/2013 Rob Weir wrote:
>>
>> I'd love to hear your thoughts on this, even if it is just a quick +1.
>
>
> Here's my quick +1, with a question: when I report a bug (typically a small
> regression) that I would like to see fixed in the possible 4.0.1 release,
> shall I already set the Target to 4.0.1? In ancient times this was left to
> the developer who had accepted the bug, but we are now less strict in
> Bugzilla usage. And setting the target to 4.0.1 would help in evaluating
> if/when we need a 4.0.1.
>
That question probably deserves its own thread. IMHO we need to
decide what a 4.0.1 is:
1) We might want to have it contain fixes for only the most urgent
bugs. We could include new translations that are available as well.
If we make that restriction then the QA impact is less. We don't need
to do a complete regression test pass. If we did that then we could
use the "release blocker" field to track these issues. We'd only fix
issues in 4.0.1 that have been discussed as release blockers.
2) Or we could open 4.0.1 up to all changes, in which case new bugs
can be introduced anywhere, possible translation impact, etc.
Personally I think 4.0.1 should be more like #1 -- strictly limited to
specific bug fixes. We then use 4.1 (the trunk) for non-urgent
fixes.
-Rob
> Regards,
> Andrea.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Andrea Pescetti <pe...@apache.org>.
On 05/08/2013 Rob Weir wrote:
> I'd love to hear your thoughts on this, even if it is just a quick +1.
Here's my quick +1, with a question: when I report a bug (typically a
small regression) that I would like to see fixed in the possible 4.0.1
release, shall I already set the Target to 4.0.1? In ancient times this
was left to the developer who had accepted the bug, but we are now less
strict in Bugzilla usage. And setting the target to 4.0.1 would help in
evaluating if/when we need a 4.0.1.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Edwin Sharp <el...@mail-page.com>.
IMHO the seven digit number (i.e. Rev. 1503704) is preferable for both report and confirmation.
Item 5 - target milestones are meant to be broken...
On Mon, Aug 5, 2013, at 18:38, Rob Weir 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Regards,
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Rainer Bielefeld <ra...@bielefeldundbuss.de>.
Rob Weir schrieb:
> I'd like to update BZ to reflect the next release of AOO.
Hi,
I am not happy with the too limited choice in the version related
selectors, for details please see "Bug 123063 - Range in all version
related selectors too limited".
Best regards
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Updating BZ versions for next releases
Posted by Andrea Pescetti <pe...@apache.org>.
On 05/08/2013 Rob Weir wrote:
> I'd love to hear your thoughts on this, even if it is just a quick +1.
Here's my quick +1, with a question: when I report a bug (typically a
small regression) that I would like to see fixed in the possible 4.0.1
release, shall I already set the Target to 4.0.1? In ancient times this
was left to the developer who had accepted the bug, but we are now less
strict in Bugzilla usage. And setting the target to 4.0.1 would help in
evaluating if/when we need a 4.0.1.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org