On Mon, May 7, 2012 at 6:58 PM, Marcus (OOo) <[email protected]> wrote: > Am 05/08/2012 12:42 AM, schrieb Rob Weir: > >> On Mon, May 7, 2012 at 6:28 PM, Marcus (OOo)<[email protected]> 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 >
