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.

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

Reply via email to