What do we need to do in BZ after AOO 3.4 is released?

[Rob Weir <ro...@apache.org>]

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?)

Add AOO341-dev?

Add AOO450-dev?

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.

-Rob

Re: What do we need to do in BZ after AOO 3.4 is released?

[Xia Zhao <li...@gmail.com>]

Suggest we add AOO 340 version as official release. And for those existing
opening defects, basically they should be moved to this version as well.
But considering we are not sure if many old defects still valid for AOO
3.4, it's better add one version as OOO and change all the defects before
AOO 3.4 to this version. To be honest, I am not sure how we handle these
large volume of old defects. From QA view, I'd like monitor those high
severity defects and verify them against AOO 340+ to check if they exist as
well.

Once AOO 340 is announced, all users can submit their feedback against AOO
340.

Also branch version should be provide to track against which version
volunteer should report issue.

For component, I totally agree Regina's suggestion.

Also one target version filed is need to track the fixed stream for given
bug.

Best regards,

Lily

2012/5/1 Rob Weir <ro...@apache.org>

> 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?)
>
> Add AOO341-dev?
>
> Add AOO450-dev?
>
> 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.
>
> -Rob
>

Re: What do we need to do in BZ after AOO 3.4 is released?

[Regina Henschel <rb...@t-online.de>]

Hi Rob,

Rob Weir schrieb:
[..]
> 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.

Yes, the list is far too large. Here some suggestions:

specs --> obsolete
We do not write specs any longer.

native-lang --> obsolete
The native-lang project had been needed to communicate and exchange 
files in native language in the beginning, when there had not been a 
Wiki. But now all native language community work can be done via 
Confluence Wiki.

Some 'products' are only relevant for core developers. There were 
distinguished, because different developer groups had exist with a 
responsible 'leader' to whom the issues could be assigned. We have no 
longer such a structure. I suggest to bundle them in a new topic, might 
be called "internal". Or move them to 'obsolete?
framework
gsl
lingucomponent
tools

Some 'products' deal with programming, not in the core, but using the 
released product. I don't know a good word for this topic. It could 
bundle the parts:
api
scripting
sdk
vba

Some 'products' where used from groups, who work on special topics. Here 
again, it is no longer necessary to communicate via Bugzilla. Perhaps we 
make an umbrella like "special project"? We can then watch, whether 
these categories are really used and if not, move them to 'obsolete' later.
bibliographic
education
marketing
performance
qa
stats
ui
wp
trademark

I'm not sure about the following:
external (rename to 'build prerequisite' and put to 'internal'?)
oopm
ucb
udk
xml

So the remaining items would be:
*Testproduct* (rename to *test submitting* for not to confuse with 
dev-builds?)
??? (=api+scripting+sdk+vba)
Chart
Database access
documentation
Drawing
extensions
Formula editor
Installation
??? internal (see above)
l10n
obsolete
Presentation
security
Spreadsheet
???special projects (see above)
Word processor
www

Kind regards
Regina

Re: What do we need to do in BZ after AOO 3.4 is released?

[Herbert Duerr <hd...@apache.org>]

> 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?)
>
> Add AOO341-dev?
>
> Add AOO450-dev?

The versions are for reporting issues against, so bugs reported from end 
users will usually be against officially released versions such as AOO340.

With only one issue reported against AOO340-dev and that one bug still 
being a problem in AOO340 just renaming the old version AOO340-dev to 
AOO340 should fine. I took the liberty to do just that.

Having bugs filed against official releases makes reproducing a problem 
easier because the binaries are easily available and widely used.

I suggest that versions such as AOO350-dev should only be used to report 
problems that don't happen on released versions, e.g. if it is a 
regression or if it involves a new feature. This also means that we 
shouldn't add versions such as AOO341-dev to bugzilla as micro releases 
are only to fix problems in the released product and they are by 
definition reproducible in the released version.

I sincerely hope that we can update to bugzilla >=4.2 soon which has the 
major new feature that obsolete versions can be marked as such.

> 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.

I like Regina's suggestions.

Herbert

Re: What do we need to do in BZ after AOO 3.4 is released?

[Rob Weir <ro...@apache.org>]

On Mon, May 7, 2012 at 6:58 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 05/08/2012 12:42 AM, schrieb Rob Weir:
>
>> On Mon, May 7, 2012 at 6:28 PM, Marcus (OOo)<ma...@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
>

Re: What do we need to do in BZ after AOO 3.4 is released?

["Marcus (OOo)" <ma...@wtnet.de>]

Am 05/08/2012 12:42 AM, schrieb Rob Weir:
> On Mon, May 7, 2012 at 6:28 PM, Marcus (OOo)<ma...@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.

> 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

Re: What do we need to do in BZ after AOO 3.4 is released?

[Rob Weir <ro...@apache.org>]

On Mon, May 7, 2012 at 6:28 PM, Marcus (OOo) <ma...@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
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.


-ROb


> Marcus

Re: What do we need to do in BZ after AOO 3.4 is released?

["Marcus (OOo)" <ma...@wtnet.de>]

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. :-)

Marcus

Re: What do we need to do in BZ after AOO 3.4 is released?

["Marcus (OOo)" <ma...@wtnet.de>]

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

Re: What do we need to do in BZ after AOO 3.4 is released?

[Juergen Schmidt <jo...@googlemail.com>]

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.
> 
> 

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