On Mon, May 7, 2012 at 6:58 PM, Marcus (OOo) <marcus.mail@wtnet.de> wrote:
> Am 05/08/2012 12:42 AM, schrieb Rob Weir:
>
>> On Mon, May 7, 2012 at 6:28 PM, Marcus (OOo)<marcus.mail@wtnet.de> wrote:
>>>
>>> Am 05/01/2012 09:28 PM, schrieb Marcus (OOo):
>>>
>>>> Am 05/01/2012 06:24 PM, schrieb Juergen Schmidt:
>>>>>
>>>>>
>>>>> On Tuesday, 1. May 2012 at 16:41, Rob Weir wrote:
>>>>>>
>>>>>>
>>>>>> Today, among the 100 version strings the users need to scroll through
>>>>>> in BZ, we have "AOO340-dev".
>>>>>>
>>>>>> What do we want after we release AOO 3.4?
>>>>>>
>>>>>> Add AOO340? (Or just rename AOO340-dev to AOO340?)
>>>>>
>>>>>
>>>>> Renaming sounds good to me and all issues with AOO340-dev should be
>>>>> moved to AOO350-dev.
>>>>> Only some special issues that we propose and discuss for a 3.4.1
>>>>> should get the AOO341-dev version
>>>>>>
>>>>>>
>>>>>>
>>>>>> Add AOO341-dev?
>>>>>>
>>>>> +1
>>>>>>
>>>>>>
>>>>>>
>>>>>> Add AOO450-dev?
>>>>>>
>>>>> you mean AOO350-dev, correct?
>>>>> If yes then +1
>>>>>
>>>>>>
>>>>>> Also, are there any "products" that can be removed or demoted to
>>>>>> "components" under another product? What we have now is simpler than
>>>>>> what we had with OOo, but it is still very complicated with a lot
of
>>>>>> "dead wood" at the top level.
>>>>
>>>>
>>>>
>>>> From JIRA I know the "Affect Version" and "Fix Version" fields which
>>>> are used to describe where the problem was seen first and where it will
>>>> be fixed.
>>>>
>>>> In BZ the "Version" field is used to describe in which version the issue
>>>> happens. The follow webpage talks about a "Target" field:
>>>>
>>>>
>>>>
>>>> https://issues.apache.org/ooo/docs/en/html/bug_page.html
>>>>
>>>> 13. *Target: (a.k.a. Target Milestone) A future version by which the bug
>>>> is to be fixed. e.g. The Bugzilla Project's milestones for future
>>>> Bugzilla versions are 2.18, 2.20, 3.0, etc. Milestones are not
>>>> restricted to numbers, thought - you can use any text strings, such as
>>>> dates.
>>>>
>>>>
>>>>
>>>> It would be very helpful to organize and keep the overview about issues
>>>> for specific versions in the future. So, could this field be enabled?
>>>>
>>>> Marcus
>>>>
>>>>
>>>>
>>>>> We should upgrade BZ to the newest version where we get more
>>>>> flexibility to disable not longer used products, versions etc.
>>>>>
>>>>> And then we should cleanup the whole BZ.
>>>>>
>>>>> Juergen
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Rob
>>>
>>>
>>>
>>> was the BZ instance already updated? I now can see a target field in
>>> issues.
>>> :-)
>>>
>>
>> Yes, I did the easy part. The restructuring part that Regina
>> suggested, we'll need to think about when to do that. By default it
>> will generate tons of notifications to ooo-issues if I make those
>> moves. We probably want to wait until a weekend to do that, and
>
>
> Or temporary disable the mail notification for this task? Maybe this is
> possible.
>
It is possible to disable all emails. That would include
notifications to ooo-issues, notifications to bug authors, owners and
"watchers", even password reset requests. So if we do that we need
schedule that for off-hours maintenance and give some advance notice
on the list.
>
>> especially wait until after the release has been out for a few days,
>> so we don't miss any urgent bug report in the traffic.
>
>
> Marcus
>