You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Shenfeng Liu <li...@gmail.com> on 2013/11/11 09:32:57 UTC
Time to start 4.1 planning?
Hi, all,
It was one month since 4.0.1 release. And I noticed some some great works
are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac
64-bit support from Herbert, and Windows Patch mechanism from Andre.
So I'm thinking, is it a good time to start the 4.1 plan now? We should
deliver those great value to our users through a formal release ASAP! And
IMO, even only the 3 items above can be enough for a release to be called
4.1. We also want to do OOXML improvement by integrating OSBA patches, and
enhance user experience like in-place Input Field, and many other things...
While, I think we can keep the continuous improvement across releases. From
the record breaking download number since 4.0 and 4.0.1, I feel that
keeping regular release is very important to response to our users, attract
more new comers, and bring this product to success.
So I suggest we start the 4.1 plan now, and set a target date. Since 4.0
was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time
for 4.1.
I suggest to update the 4.1 planning wiki[1] and:
(1) Set the target date.
(2) Clean up the planning list, starting from leaving only the active
items, and moving the rest to project backlog[2].
Any suggestion/comments?
[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
[2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog
- Shenfeng (Simon)
Re: Time to start 4.1 planning?
Posted by Shenfeng Liu <li...@gmail.com>.
I just updated the 4.1 planning wiki[1]:
(1) I added the section of "Proposed Release Schedule", including the beta.
But I left most of the milestones <TBD>.
(2) I created a wiki page of "AOO Feature Enhancement Backlog"[2], and left
only those active items (per my reading from the dev list) in 4.1, but
moved the rest to this backlog.
Any comments are welcome!
[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
[2]
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Feature+Enhancement+Backlog
- Shenfeng (Simon)
2013/11/13 Marcus (OOo) <ma...@wtnet.de>
> Am 11/12/2013 10:36 PM, schrieb Rob Weir:
>
> On Tue, Nov 12, 2013 at 3:51 PM, Marcus (OOo)<ma...@wtnet.de>
>> wrote:
>>
>>> Am 11/11/2013 10:33 PM, schrieb Rob Weir:
>>>
>>> On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)<ma...@wtnet.de>
>>>> wrote:
>>>>
>>>>>
>>>>> Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt:
>>>>>
>>>>> On 11/11/13 3:59 PM, Rob Weir wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu<li...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi, all,
>>>>>>>> It was one month since 4.0.1 release. And I noticed some some
>>>>>>>> great
>>>>>>>> works
>>>>>>>> are going to be delivered soon. e.g. the IA2 framework from Steve,
>>>>>>>> the
>>>>>>>> Mac
>>>>>>>> 64-bit support from Herbert, and Windows Patch mechanism from Andre.
>>>>>>>>
>>>>>>>> So I'm thinking, is it a good time to start the 4.1 plan now?
>>>>>>>> We
>>>>>>>> should
>>>>>>>> deliver those great value to our users through a formal release
>>>>>>>> ASAP!
>>>>>>>> And
>>>>>>>> IMO, even only the 3 items above can be enough for a release to be
>>>>>>>> called
>>>>>>>> 4.1. We also want to do OOXML improvement by integrating OSBA
>>>>>>>> patches,
>>>>>>>> and
>>>>>>>> enhance user experience like in-place Input Field, and many other
>>>>>>>> things...
>>>>>>>> While, I think we can keep the continuous improvement across
>>>>>>>> releases.
>>>>>>>> From
>>>>>>>> the record breaking download number since 4.0 and 4.0.1, I feel that
>>>>>>>> keeping regular release is very important to response to our users,
>>>>>>>> attract
>>>>>>>> more new comers, and bring this product to success.
>>>>>>>>
>>>>>>>> So I suggest we start the 4.1 plan now, and set a target date.
>>>>>>>> Since
>>>>>>>> 4.0
>>>>>>>> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good
>>>>>>>> time
>>>>>>>> for 4.1.
>>>>>>>>
>>>>>>>>
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> Something to think about: After 4.0.0 we discussed having a public
>>>>>>> beta with out next major release. If we think this is worth doing,
>>>>>>> then we should plan on two dates: 1) A public beta data, and 2) a
>>>>>>> final release date. For the beta to be useful I think we would want
>>>>>>> it to last 3-4 weeks, enough time to process any new bug reports,
>>>>>>> identify any critical regressions, and fix them.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 4 weeks between both is a minimum form my pov
>>>>>>
>>>>>> But having a beta is of course the route we should take.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> What about taking into account to keep the possibility to release a
>>>>> second
>>>>> Beta version? It can include fixes for the most nasty and prominent
>>>>> bugs.
>>>>>
>>>>>
>>>> Well, hopefully we do some amount of testing before we have a beta.
>>>> So the goal should be for the beta to have no "nasty and prominent"
>>>> bugs. The beta is a form of insurance and a way of setting
>>>> expectations.
>>>>
>>>> For example, I think these two scenarios are technically equivalent:
>>>>
>>>> a) release 4.1.0 after normal testing
>>>>
>>>> b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing.
>>>>
>>>> and
>>>>
>>>> a') release 4.1.0 beta after normal testing
>>>>
>>>> b') release 4.1.0 GA after fixing important bugs found in beta
>>>>
>>>
>>>
>>> Sure but we want to do a testing phase in public and not just
>>> technically.
>>>
>>>
>>> These are technically the same, and take approximately the same amount
>>>> of time. The difference is in user expectations. A "beta"
>>>> designation tells the cautious user to avoid it. It encourages users
>>>> who are willing to take more risk and help us by giving feedback. It
>>>> also helps preserve the brand reputation by ensuring that the actual
>>>> GA releases are high quality.
>>>>
>>>> (If we're not careful the users will develop a sense to avoid all
>>>> x.y.0 releases, believing them to be low quality. Other products have
>>>> run into that problem, even with x.y.1 and x.y.2 releases. I think it
>>>> is better if we can avoid having that kind of reputation.)
>>>>
>>>
>>>
>>> Intersting, one can understand your arguments as points to *do* a second
>>> Beta release. ;-)
>>>
>>>
>>> A 2nd beta might be necessary in some rare cases, but I think in most
>>>> cases we fix the critical bugs found in the beta and just do normal
>>>> re-testing of those areas in a Release Candidate.
>>>>
>>>
>>>
>>> Still no point not to do a second release.
>>>
>>> But before you go on with writting, please understand my suggestion as
>>> simple suggestion. I don't want to force it. When you deny it with a
>>> short
>>> post, then it's fine. No need to find many arguments that speak (maybe)
>>> against it. ;-)
>>>
>>>
>> I'm not necessarily opposed to have 2, or even 3 betas. (Ha!). But I
>> say let the facts, not preconceptions, determine what we do. Let's do
>> a beta, look at the results, discuss and then determine the next
>>
>
> Great, then you have understood what I wanted to say.
>
> Marcus
>
>
>
>
> steps. I *predict* that only one beta will be needed. But I'm not
>> insisting on it.
>>
>> Regards,
>>
>> -Rob
>>
>> Marcus
>>>
>>>
>>>
>>>
>>> If we agree on that, we should expand the timeframe to 6 or more weeks.
>>>>>
>>>>> My 2 ct.
>>>>>
>>>>> Marcus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I suggest to update the 4.1 planning wiki[1] and:
>>>>>>>> (1) Set the target date.
>>>>>>>> (2) Clean up the planning list, starting from leaving only the
>>>>>>>> active
>>>>>>>> items, and moving the rest to project backlog[2].
>>>>>>>>
>>>>>>>> Any suggestion/comments?
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/
>>>>>>>> AOO+4.1+Release+Planning
>>>>>>>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/
>>>>>>>> Project+Blog
>>>>>>>>
>>>>>>>>
>>>>>>>> - Shenfeng (Simon)
>>>>>>>>
>>>>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Time to start 4.1 planning?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 11/12/2013 10:36 PM, schrieb Rob Weir:
> On Tue, Nov 12, 2013 at 3:51 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 11/11/2013 10:33 PM, schrieb Rob Weir:
>>
>>> On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)<ma...@wtnet.de>
>>> wrote:
>>>>
>>>> Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt:
>>>>
>>>>> On 11/11/13 3:59 PM, Rob Weir wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu<li...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi, all,
>>>>>>> It was one month since 4.0.1 release. And I noticed some some
>>>>>>> great
>>>>>>> works
>>>>>>> are going to be delivered soon. e.g. the IA2 framework from Steve, the
>>>>>>> Mac
>>>>>>> 64-bit support from Herbert, and Windows Patch mechanism from Andre.
>>>>>>>
>>>>>>> So I'm thinking, is it a good time to start the 4.1 plan now? We
>>>>>>> should
>>>>>>> deliver those great value to our users through a formal release ASAP!
>>>>>>> And
>>>>>>> IMO, even only the 3 items above can be enough for a release to be
>>>>>>> called
>>>>>>> 4.1. We also want to do OOXML improvement by integrating OSBA patches,
>>>>>>> and
>>>>>>> enhance user experience like in-place Input Field, and many other
>>>>>>> things...
>>>>>>> While, I think we can keep the continuous improvement across releases.
>>>>>>> From
>>>>>>> the record breaking download number since 4.0 and 4.0.1, I feel that
>>>>>>> keeping regular release is very important to response to our users,
>>>>>>> attract
>>>>>>> more new comers, and bring this product to success.
>>>>>>>
>>>>>>> So I suggest we start the 4.1 plan now, and set a target date.
>>>>>>> Since
>>>>>>> 4.0
>>>>>>> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good
>>>>>>> time
>>>>>>> for 4.1.
>>>>>>>
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> Something to think about: After 4.0.0 we discussed having a public
>>>>>> beta with out next major release. If we think this is worth doing,
>>>>>> then we should plan on two dates: 1) A public beta data, and 2) a
>>>>>> final release date. For the beta to be useful I think we would want
>>>>>> it to last 3-4 weeks, enough time to process any new bug reports,
>>>>>> identify any critical regressions, and fix them.
>>>>>
>>>>>
>>>>>
>>>>> 4 weeks between both is a minimum form my pov
>>>>>
>>>>> But having a beta is of course the route we should take.
>>>>
>>>>
>>>>
>>>> What about taking into account to keep the possibility to release a
>>>> second
>>>> Beta version? It can include fixes for the most nasty and prominent bugs.
>>>>
>>>
>>> Well, hopefully we do some amount of testing before we have a beta.
>>> So the goal should be for the beta to have no "nasty and prominent"
>>> bugs. The beta is a form of insurance and a way of setting
>>> expectations.
>>>
>>> For example, I think these two scenarios are technically equivalent:
>>>
>>> a) release 4.1.0 after normal testing
>>>
>>> b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing.
>>>
>>> and
>>>
>>> a') release 4.1.0 beta after normal testing
>>>
>>> b') release 4.1.0 GA after fixing important bugs found in beta
>>
>>
>> Sure but we want to do a testing phase in public and not just technically.
>>
>>
>>> These are technically the same, and take approximately the same amount
>>> of time. The difference is in user expectations. A "beta"
>>> designation tells the cautious user to avoid it. It encourages users
>>> who are willing to take more risk and help us by giving feedback. It
>>> also helps preserve the brand reputation by ensuring that the actual
>>> GA releases are high quality.
>>>
>>> (If we're not careful the users will develop a sense to avoid all
>>> x.y.0 releases, believing them to be low quality. Other products have
>>> run into that problem, even with x.y.1 and x.y.2 releases. I think it
>>> is better if we can avoid having that kind of reputation.)
>>
>>
>> Intersting, one can understand your arguments as points to *do* a second
>> Beta release. ;-)
>>
>>
>>> A 2nd beta might be necessary in some rare cases, but I think in most
>>> cases we fix the critical bugs found in the beta and just do normal
>>> re-testing of those areas in a Release Candidate.
>>
>>
>> Still no point not to do a second release.
>>
>> But before you go on with writting, please understand my suggestion as
>> simple suggestion. I don't want to force it. When you deny it with a short
>> post, then it's fine. No need to find many arguments that speak (maybe)
>> against it. ;-)
>>
>
> I'm not necessarily opposed to have 2, or even 3 betas. (Ha!). But I
> say let the facts, not preconceptions, determine what we do. Let's do
> a beta, look at the results, discuss and then determine the next
Great, then you have understood what I wanted to say.
Marcus
> steps. I *predict* that only one beta will be needed. But I'm not
> insisting on it.
>
> Regards,
>
> -Rob
>
>> Marcus
>>
>>
>>
>>
>>>> If we agree on that, we should expand the timeframe to 6 or more weeks.
>>>>
>>>> My 2 ct.
>>>>
>>>> Marcus
>>>>
>>>>
>>>>
>>>>
>>>>>>> I suggest to update the 4.1 planning wiki[1] and:
>>>>>>> (1) Set the target date.
>>>>>>> (2) Clean up the planning list, starting from leaving only the active
>>>>>>> items, and moving the rest to project backlog[2].
>>>>>>>
>>>>>>> Any suggestion/comments?
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
>>>>>>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog
>>>>>>>
>>>>>>>
>>>>>>> - Shenfeng (Simon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Time to start 4.1 planning?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Nov 12, 2013 at 3:51 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 11/11/2013 10:33 PM, schrieb Rob Weir:
>
>> On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)<ma...@wtnet.de>
>> wrote:
>>>
>>> Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt:
>>>
>>>> On 11/11/13 3:59 PM, Rob Weir wrote:
>>>>>
>>>>>
>>>>> On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu<li...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi, all,
>>>>>> It was one month since 4.0.1 release. And I noticed some some
>>>>>> great
>>>>>> works
>>>>>> are going to be delivered soon. e.g. the IA2 framework from Steve, the
>>>>>> Mac
>>>>>> 64-bit support from Herbert, and Windows Patch mechanism from Andre.
>>>>>>
>>>>>> So I'm thinking, is it a good time to start the 4.1 plan now? We
>>>>>> should
>>>>>> deliver those great value to our users through a formal release ASAP!
>>>>>> And
>>>>>> IMO, even only the 3 items above can be enough for a release to be
>>>>>> called
>>>>>> 4.1. We also want to do OOXML improvement by integrating OSBA patches,
>>>>>> and
>>>>>> enhance user experience like in-place Input Field, and many other
>>>>>> things...
>>>>>> While, I think we can keep the continuous improvement across releases.
>>>>>> From
>>>>>> the record breaking download number since 4.0 and 4.0.1, I feel that
>>>>>> keeping regular release is very important to response to our users,
>>>>>> attract
>>>>>> more new comers, and bring this product to success.
>>>>>>
>>>>>> So I suggest we start the 4.1 plan now, and set a target date.
>>>>>> Since
>>>>>> 4.0
>>>>>> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good
>>>>>> time
>>>>>> for 4.1.
>>>>>>
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> Something to think about: After 4.0.0 we discussed having a public
>>>>> beta with out next major release. If we think this is worth doing,
>>>>> then we should plan on two dates: 1) A public beta data, and 2) a
>>>>> final release date. For the beta to be useful I think we would want
>>>>> it to last 3-4 weeks, enough time to process any new bug reports,
>>>>> identify any critical regressions, and fix them.
>>>>
>>>>
>>>>
>>>> 4 weeks between both is a minimum form my pov
>>>>
>>>> But having a beta is of course the route we should take.
>>>
>>>
>>>
>>> What about taking into account to keep the possibility to release a
>>> second
>>> Beta version? It can include fixes for the most nasty and prominent bugs.
>>>
>>
>> Well, hopefully we do some amount of testing before we have a beta.
>> So the goal should be for the beta to have no "nasty and prominent"
>> bugs. The beta is a form of insurance and a way of setting
>> expectations.
>>
>> For example, I think these two scenarios are technically equivalent:
>>
>> a) release 4.1.0 after normal testing
>>
>> b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing.
>>
>> and
>>
>> a') release 4.1.0 beta after normal testing
>>
>> b') release 4.1.0 GA after fixing important bugs found in beta
>
>
> Sure but we want to do a testing phase in public and not just technically.
>
>
>> These are technically the same, and take approximately the same amount
>> of time. The difference is in user expectations. A "beta"
>> designation tells the cautious user to avoid it. It encourages users
>> who are willing to take more risk and help us by giving feedback. It
>> also helps preserve the brand reputation by ensuring that the actual
>> GA releases are high quality.
>>
>> (If we're not careful the users will develop a sense to avoid all
>> x.y.0 releases, believing them to be low quality. Other products have
>> run into that problem, even with x.y.1 and x.y.2 releases. I think it
>> is better if we can avoid having that kind of reputation.)
>
>
> Intersting, one can understand your arguments as points to *do* a second
> Beta release. ;-)
>
>
>> A 2nd beta might be necessary in some rare cases, but I think in most
>> cases we fix the critical bugs found in the beta and just do normal
>> re-testing of those areas in a Release Candidate.
>
>
> Still no point not to do a second release.
>
> But before you go on with writting, please understand my suggestion as
> simple suggestion. I don't want to force it. When you deny it with a short
> post, then it's fine. No need to find many arguments that speak (maybe)
> against it. ;-)
>
I'm not necessarily opposed to have 2, or even 3 betas. (Ha!). But I
say let the facts, not preconceptions, determine what we do. Let's do
a beta, look at the results, discuss and then determine the next
steps. I *predict* that only one beta will be needed. But I'm not
insisting on it.
Regards,
-Rob
> Marcus
>
>
>
>
>>> If we agree on that, we should expand the timeframe to 6 or more weeks.
>>>
>>> My 2 ct.
>>>
>>> Marcus
>>>
>>>
>>>
>>>
>>>>>> I suggest to update the 4.1 planning wiki[1] and:
>>>>>> (1) Set the target date.
>>>>>> (2) Clean up the planning list, starting from leaving only the active
>>>>>> items, and moving the rest to project backlog[2].
>>>>>>
>>>>>> Any suggestion/comments?
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
>>>>>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog
>>>>>>
>>>>>>
>>>>>> - Shenfeng (Simon)
>
>
> ---------------------------------------------------------------------
> 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: Time to start 4.1 planning?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 11/11/2013 10:33 PM, schrieb Rob Weir:
> On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt:
>>
>>> On 11/11/13 3:59 PM, Rob Weir wrote:
>>>>
>>>> On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu<li...@gmail.com> wrote:
>>>>>
>>>>> Hi, all,
>>>>> It was one month since 4.0.1 release. And I noticed some some great
>>>>> works
>>>>> are going to be delivered soon. e.g. the IA2 framework from Steve, the
>>>>> Mac
>>>>> 64-bit support from Herbert, and Windows Patch mechanism from Andre.
>>>>>
>>>>> So I'm thinking, is it a good time to start the 4.1 plan now? We
>>>>> should
>>>>> deliver those great value to our users through a formal release ASAP!
>>>>> And
>>>>> IMO, even only the 3 items above can be enough for a release to be
>>>>> called
>>>>> 4.1. We also want to do OOXML improvement by integrating OSBA patches,
>>>>> and
>>>>> enhance user experience like in-place Input Field, and many other
>>>>> things...
>>>>> While, I think we can keep the continuous improvement across releases.
>>>>> From
>>>>> the record breaking download number since 4.0 and 4.0.1, I feel that
>>>>> keeping regular release is very important to response to our users,
>>>>> attract
>>>>> more new comers, and bring this product to success.
>>>>>
>>>>> So I suggest we start the 4.1 plan now, and set a target date. Since
>>>>> 4.0
>>>>> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good
>>>>> time
>>>>> for 4.1.
>>>>>
>>>>
>>>> Hi Simon,
>>>>
>>>> Something to think about: After 4.0.0 we discussed having a public
>>>> beta with out next major release. If we think this is worth doing,
>>>> then we should plan on two dates: 1) A public beta data, and 2) a
>>>> final release date. For the beta to be useful I think we would want
>>>> it to last 3-4 weeks, enough time to process any new bug reports,
>>>> identify any critical regressions, and fix them.
>>>
>>>
>>> 4 weeks between both is a minimum form my pov
>>>
>>> But having a beta is of course the route we should take.
>>
>>
>> What about taking into account to keep the possibility to release a second
>> Beta version? It can include fixes for the most nasty and prominent bugs.
>>
>
> Well, hopefully we do some amount of testing before we have a beta.
> So the goal should be for the beta to have no "nasty and prominent"
> bugs. The beta is a form of insurance and a way of setting
> expectations.
>
> For example, I think these two scenarios are technically equivalent:
>
> a) release 4.1.0 after normal testing
>
> b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing.
>
> and
>
> a') release 4.1.0 beta after normal testing
>
> b') release 4.1.0 GA after fixing important bugs found in beta
Sure but we want to do a testing phase in public and not just technically.
> These are technically the same, and take approximately the same amount
> of time. The difference is in user expectations. A "beta"
> designation tells the cautious user to avoid it. It encourages users
> who are willing to take more risk and help us by giving feedback. It
> also helps preserve the brand reputation by ensuring that the actual
> GA releases are high quality.
>
> (If we're not careful the users will develop a sense to avoid all
> x.y.0 releases, believing them to be low quality. Other products have
> run into that problem, even with x.y.1 and x.y.2 releases. I think it
> is better if we can avoid having that kind of reputation.)
Intersting, one can understand your arguments as points to *do* a second
Beta release. ;-)
> A 2nd beta might be necessary in some rare cases, but I think in most
> cases we fix the critical bugs found in the beta and just do normal
> re-testing of those areas in a Release Candidate.
Still no point not to do a second release.
But before you go on with writting, please understand my suggestion as
simple suggestion. I don't want to force it. When you deny it with a
short post, then it's fine. No need to find many arguments that speak
(maybe) against it. ;-)
Marcus
>> If we agree on that, we should expand the timeframe to 6 or more weeks.
>>
>> My 2 ct.
>>
>> Marcus
>>
>>
>>
>>
>>>>> I suggest to update the 4.1 planning wiki[1] and:
>>>>> (1) Set the target date.
>>>>> (2) Clean up the planning list, starting from leaving only the active
>>>>> items, and moving the rest to project backlog[2].
>>>>>
>>>>> Any suggestion/comments?
>>>>>
>>>>>
>>>>> [1]
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
>>>>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog
>>>>>
>>>>>
>>>>> - Shenfeng (Simon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Time to start 4.1 planning?
Posted by Shenfeng Liu <li...@gmail.com>.
2013/11/12 Rob Weir <ro...@apache.org>
> On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo) <ma...@wtnet.de>
> wrote:
> > Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt:
> >
> >> On 11/11/13 3:59 PM, Rob Weir wrote:
> >>>
> >>> On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu<li...@gmail.com>
> wrote:
> >>>>
> >>>> Hi, all,
> >>>> It was one month since 4.0.1 release. And I noticed some some great
> >>>> works
> >>>> are going to be delivered soon. e.g. the IA2 framework from Steve, the
> >>>> Mac
> >>>> 64-bit support from Herbert, and Windows Patch mechanism from Andre.
> >>>>
> >>>> So I'm thinking, is it a good time to start the 4.1 plan now? We
> >>>> should
> >>>> deliver those great value to our users through a formal release ASAP!
> >>>> And
> >>>> IMO, even only the 3 items above can be enough for a release to be
> >>>> called
> >>>> 4.1. We also want to do OOXML improvement by integrating OSBA patches,
> >>>> and
> >>>> enhance user experience like in-place Input Field, and many other
> >>>> things...
> >>>> While, I think we can keep the continuous improvement across releases.
> >>>> From
> >>>> the record breaking download number since 4.0 and 4.0.1, I feel that
> >>>> keeping regular release is very important to response to our users,
> >>>> attract
> >>>> more new comers, and bring this product to success.
> >>>>
> >>>> So I suggest we start the 4.1 plan now, and set a target date.
> Since
> >>>> 4.0
> >>>> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good
> >>>> time
> >>>> for 4.1.
> >>>>
> >>>
> >>> Hi Simon,
> >>>
> >>> Something to think about: After 4.0.0 we discussed having a public
> >>> beta with out next major release. If we think this is worth doing,
> >>> then we should plan on two dates: 1) A public beta data, and 2) a
> >>> final release date. For the beta to be useful I think we would want
> >>> it to last 3-4 weeks, enough time to process any new bug reports,
> >>> identify any critical regressions, and fix them.
> >>
> >>
> >> 4 weeks between both is a minimum form my pov
> >>
> >> But having a beta is of course the route we should take.
> >
> >
> > What about taking into account to keep the possibility to release a
> second
> > Beta version? It can include fixes for the most nasty and prominent bugs.
> >
>
> Well, hopefully we do some amount of testing before we have a beta.
> So the goal should be for the beta to have no "nasty and prominent"
> bugs. The beta is a form of insurance and a way of setting
> expectations.
>
> For example, I think these two scenarios are technically equivalent:
>
> a) release 4.1.0 after normal testing
>
> b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing.
>
> and
>
> a') release 4.1.0 beta after normal testing
>
> b') release 4.1.0 GA after fixing important bugs found in beta
>
> These are technically the same, and take approximately the same amount
> of time. The difference is in user expectations. A "beta"
> designation tells the cautious user to avoid it. It encourages users
> who are willing to take more risk and help us by giving feedback. It
> also helps preserve the brand reputation by ensuring that the actual
> GA releases are high quality.
>
> (If we're not careful the users will develop a sense to avoid all
> x.y.0 releases, believing them to be low quality. Other products have
> run into that problem, even with x.y.1 and x.y.2 releases. I think it
> is better if we can avoid having that kind of reputation.)
>
> A 2nd beta might be necessary in some rare cases, but I think in most
> cases we fix the critical bugs found in the beta and just do normal
> re-testing of those areas in a Release Candidate.
>
>
Hi, Rob,
I think a public beta is a good idea!
After the 4.1 feature development and related FVT completed, I think we
kick off a beta testing which cover the major function areas, then announce
the 4.1 beta.
Then we run the Full Regression Test and monitor the beta feedback, from
4.0 experience the Full Regression Test will take at least 4 weeks, depends
on the number of volunteers. Then the end game critical fix and RC build
testing for 4.1.
- Shenfeng (Simon)
> Regards,
>
> -Rob
>
>
>
> > If we agree on that, we should expand the timeframe to 6 or more weeks.
> >
> > My 2 ct.
> >
> > Marcus
> >
> >
> >
> >
> >>>> I suggest to update the 4.1 planning wiki[1] and:
> >>>> (1) Set the target date.
> >>>> (2) Clean up the planning list, starting from leaving only the active
> >>>> items, and moving the rest to project backlog[2].
> >>>>
> >>>> Any suggestion/comments?
> >>>>
> >>>>
> >>>> [1]
> >>>>
> >>>>
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
> >>>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog
> >>>>
> >>>>
> >>>> - Shenfeng (Simon)
> >
> >
> > ---------------------------------------------------------------------
> > 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: Time to start 4.1 planning?
Posted by Rob Weir <ro...@apache.org>.
On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt:
>
>> On 11/11/13 3:59 PM, Rob Weir wrote:
>>>
>>> On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu<li...@gmail.com> wrote:
>>>>
>>>> Hi, all,
>>>> It was one month since 4.0.1 release. And I noticed some some great
>>>> works
>>>> are going to be delivered soon. e.g. the IA2 framework from Steve, the
>>>> Mac
>>>> 64-bit support from Herbert, and Windows Patch mechanism from Andre.
>>>>
>>>> So I'm thinking, is it a good time to start the 4.1 plan now? We
>>>> should
>>>> deliver those great value to our users through a formal release ASAP!
>>>> And
>>>> IMO, even only the 3 items above can be enough for a release to be
>>>> called
>>>> 4.1. We also want to do OOXML improvement by integrating OSBA patches,
>>>> and
>>>> enhance user experience like in-place Input Field, and many other
>>>> things...
>>>> While, I think we can keep the continuous improvement across releases.
>>>> From
>>>> the record breaking download number since 4.0 and 4.0.1, I feel that
>>>> keeping regular release is very important to response to our users,
>>>> attract
>>>> more new comers, and bring this product to success.
>>>>
>>>> So I suggest we start the 4.1 plan now, and set a target date. Since
>>>> 4.0
>>>> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good
>>>> time
>>>> for 4.1.
>>>>
>>>
>>> Hi Simon,
>>>
>>> Something to think about: After 4.0.0 we discussed having a public
>>> beta with out next major release. If we think this is worth doing,
>>> then we should plan on two dates: 1) A public beta data, and 2) a
>>> final release date. For the beta to be useful I think we would want
>>> it to last 3-4 weeks, enough time to process any new bug reports,
>>> identify any critical regressions, and fix them.
>>
>>
>> 4 weeks between both is a minimum form my pov
>>
>> But having a beta is of course the route we should take.
>
>
> What about taking into account to keep the possibility to release a second
> Beta version? It can include fixes for the most nasty and prominent bugs.
>
Well, hopefully we do some amount of testing before we have a beta.
So the goal should be for the beta to have no "nasty and prominent"
bugs. The beta is a form of insurance and a way of setting
expectations.
For example, I think these two scenarios are technically equivalent:
a) release 4.1.0 after normal testing
b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing.
and
a') release 4.1.0 beta after normal testing
b') release 4.1.0 GA after fixing important bugs found in beta
These are technically the same, and take approximately the same amount
of time. The difference is in user expectations. A "beta"
designation tells the cautious user to avoid it. It encourages users
who are willing to take more risk and help us by giving feedback. It
also helps preserve the brand reputation by ensuring that the actual
GA releases are high quality.
(If we're not careful the users will develop a sense to avoid all
x.y.0 releases, believing them to be low quality. Other products have
run into that problem, even with x.y.1 and x.y.2 releases. I think it
is better if we can avoid having that kind of reputation.)
A 2nd beta might be necessary in some rare cases, but I think in most
cases we fix the critical bugs found in the beta and just do normal
re-testing of those areas in a Release Candidate.
Regards,
-Rob
> If we agree on that, we should expand the timeframe to 6 or more weeks.
>
> My 2 ct.
>
> Marcus
>
>
>
>
>>>> I suggest to update the 4.1 planning wiki[1] and:
>>>> (1) Set the target date.
>>>> (2) Clean up the planning list, starting from leaving only the active
>>>> items, and moving the rest to project backlog[2].
>>>>
>>>> Any suggestion/comments?
>>>>
>>>>
>>>> [1]
>>>>
>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
>>>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog
>>>>
>>>>
>>>> - Shenfeng (Simon)
>
>
> ---------------------------------------------------------------------
> 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: Time to start 4.1 planning?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt:
> On 11/11/13 3:59 PM, Rob Weir wrote:
>> On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu<li...@gmail.com> wrote:
>>> Hi, all,
>>> It was one month since 4.0.1 release. And I noticed some some great works
>>> are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac
>>> 64-bit support from Herbert, and Windows Patch mechanism from Andre.
>>>
>>> So I'm thinking, is it a good time to start the 4.1 plan now? We should
>>> deliver those great value to our users through a formal release ASAP! And
>>> IMO, even only the 3 items above can be enough for a release to be called
>>> 4.1. We also want to do OOXML improvement by integrating OSBA patches, and
>>> enhance user experience like in-place Input Field, and many other things...
>>> While, I think we can keep the continuous improvement across releases. From
>>> the record breaking download number since 4.0 and 4.0.1, I feel that
>>> keeping regular release is very important to response to our users, attract
>>> more new comers, and bring this product to success.
>>>
>>> So I suggest we start the 4.1 plan now, and set a target date. Since 4.0
>>> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time
>>> for 4.1.
>>>
>>
>> Hi Simon,
>>
>> Something to think about: After 4.0.0 we discussed having a public
>> beta with out next major release. If we think this is worth doing,
>> then we should plan on two dates: 1) A public beta data, and 2) a
>> final release date. For the beta to be useful I think we would want
>> it to last 3-4 weeks, enough time to process any new bug reports,
>> identify any critical regressions, and fix them.
>
> 4 weeks between both is a minimum form my pov
>
> But having a beta is of course the route we should take.
What about taking into account to keep the possibility to release a
second Beta version? It can include fixes for the most nasty and
prominent bugs.
If we agree on that, we should expand the timeframe to 6 or more weeks.
My 2 ct.
Marcus
>>> I suggest to update the 4.1 planning wiki[1] and:
>>> (1) Set the target date.
>>> (2) Clean up the planning list, starting from leaving only the active
>>> items, and moving the rest to project backlog[2].
>>>
>>> Any suggestion/comments?
>>>
>>>
>>> [1]
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
>>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog
>>>
>>>
>>> - Shenfeng (Simon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Time to start 4.1 planning?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 11/11/13 3:59 PM, Rob Weir wrote:
> On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu <li...@gmail.com> wrote:
>> Hi, all,
>> It was one month since 4.0.1 release. And I noticed some some great works
>> are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac
>> 64-bit support from Herbert, and Windows Patch mechanism from Andre.
>>
>> So I'm thinking, is it a good time to start the 4.1 plan now? We should
>> deliver those great value to our users through a formal release ASAP! And
>> IMO, even only the 3 items above can be enough for a release to be called
>> 4.1. We also want to do OOXML improvement by integrating OSBA patches, and
>> enhance user experience like in-place Input Field, and many other things...
>> While, I think we can keep the continuous improvement across releases. From
>> the record breaking download number since 4.0 and 4.0.1, I feel that
>> keeping regular release is very important to response to our users, attract
>> more new comers, and bring this product to success.
>>
>> So I suggest we start the 4.1 plan now, and set a target date. Since 4.0
>> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time
>> for 4.1.
>>
>
> Hi Simon,
>
> Something to think about: After 4.0.0 we discussed having a public
> beta with out next major release. If we think this is worth doing,
> then we should plan on two dates: 1) A public beta data, and 2) a
> final release date. For the beta to be useful I think we would want
> it to last 3-4 weeks, enough time to process any new bug reports,
> identify any critical regressions, and fix them.
4 weeks between both is a minimum form my pov
But having a beta is of course the route we should take.
Juergen
>
> Regards,
>
> -Rob
>
>
>> I suggest to update the 4.1 planning wiki[1] and:
>> (1) Set the target date.
>> (2) Clean up the planning list, starting from leaving only the active
>> items, and moving the rest to project backlog[2].
>>
>> Any suggestion/comments?
>>
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog
>>
>>
>> - Shenfeng (Simon)
>
> ---------------------------------------------------------------------
> 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: Time to start 4.1 planning?
Posted by Rob Weir <ro...@apache.org>.
On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu <li...@gmail.com> wrote:
> Hi, all,
> It was one month since 4.0.1 release. And I noticed some some great works
> are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac
> 64-bit support from Herbert, and Windows Patch mechanism from Andre.
>
> So I'm thinking, is it a good time to start the 4.1 plan now? We should
> deliver those great value to our users through a formal release ASAP! And
> IMO, even only the 3 items above can be enough for a release to be called
> 4.1. We also want to do OOXML improvement by integrating OSBA patches, and
> enhance user experience like in-place Input Field, and many other things...
> While, I think we can keep the continuous improvement across releases. From
> the record breaking download number since 4.0 and 4.0.1, I feel that
> keeping regular release is very important to response to our users, attract
> more new comers, and bring this product to success.
>
> So I suggest we start the 4.1 plan now, and set a target date. Since 4.0
> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time
> for 4.1.
>
Hi Simon,
Something to think about: After 4.0.0 we discussed having a public
beta with out next major release. If we think this is worth doing,
then we should plan on two dates: 1) A public beta data, and 2) a
final release date. For the beta to be useful I think we would want
it to last 3-4 weeks, enough time to process any new bug reports,
identify any critical regressions, and fix them.
Regards,
-Rob
> I suggest to update the 4.1 planning wiki[1] and:
> (1) Set the target date.
> (2) Clean up the planning list, starting from leaving only the active
> items, and moving the rest to project backlog[2].
>
> Any suggestion/comments?
>
>
> [1]
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning
> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog
>
>
> - Shenfeng (Simon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org