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) <marcus.m...@wtnet.de> > Am 11/12/2013 10:36 PM, schrieb Rob Weir: > > On Tue, Nov 12, 2013 at 3:51 PM, Marcus (OOo)<marcus.m...@wtnet.de> >> wrote: >> >>> Am 11/11/2013 10:33 PM, schrieb Rob Weir: >>> >>> On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)<marcus.m...@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<liush...@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-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
