Hi, all, I'm just back from China Mid-Autumn/National-Day holidays. So I'd like to pick up the milestone build topic again. We already get the support from QE team for the test plan. So I think we need to do the following:
1. build out the milestone build. I saw from the buildbot that we have the Windows and Linux-64 build successfully today. So it can be the candidate of our first milestone build. While my question are: (1) Can we add more platforms (e.g. Mac, Linux-32, OS2...)? They need to be built manually. (2) How many language support can we get for this milestone build? Not necessary to be 100% translated, but can be a base for volunteers to verify the translation. (3) The current development snapshot naming [a] is a little confusing to me. I wonder if we can change the naming to reflect the date of the build? 2. upload the build and update the development snapshot wiki [a]. 3. Run the testing against the build. 4. prepare related documents. (1) update the release notes wiki [b] for new values in this milestone build. (2) a wiki page to record the testing result to this milestone build. (2) a web page to announce this milestone build. I can contribute to #4. Any thing else to add? Or any suggestion/comments? - Simon [a] https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds [b] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Notes 2012/9/27 Shenfeng Liu <liush...@gmail.com> > Xue Fei, > I think BVT + fidelity automation will be good. > And since we are still facing the buildbots limitation, we can start > from only some of the platforms and expand to more gradually. > Thanks! > > - Simon > > > > 2012/9/27 Xue Fei Duan <duanx...@gmail.com> > >> For milestone build, I think BVT + fidelity automation(load/save some >> samples) running is ok. we needn't have extra test plan on it, how do you >> think about it? >> -Xue Fei >> >> On Wed, Sep 26, 2012 at 6:50 PM, Shenfeng Liu <liush...@gmail.com> wrote: >> >> > 2012/9/26 Ji Yan <yanji...@gmail.com> >> > >> > > Simon, >> > > >> > > IMO, milestone test plan should base on milestone schedule and >> feature >> > > plan, what feature goes in and which defects are fixed in this >> milestone. >> > > Based on this scope we can define our testing plan. Otherwise we are >> > > running into target unclear testing, defects will be missed. >> > > >> > > >> > Ji, >> > Thanks for your complete thought! >> > While IMO, the milestone build is still a development snapshot. We >> don't >> > need to ensure a kind of GA quality on it. And we just need to ensure >> this >> > build: >> > >> > 1. Will not cause data lost (e.g. damage the file in editing). >> > 2. Will not lead to operation system crash. >> > 3. No severe defects that blocks user to try out the new features in >> this >> > build. >> > >> > Of course we need to test the new features, but I think it should >> fall to >> > another category of our planned testing. And for milestone build >> testing, I >> > think an acceptance test should be able to cover above goals, and we can >> > record the tested scenarios/platforms/languages on a wiki page. >> > We don't need to define a perfect test plan from beginning. Let's just >> > practise and refine. >> > >> > - Simon >> > >> > >> > >> > > 2012/9/26 Shenfeng Liu <liush...@gmail.com> >> > > >> > > > 2012/9/26 Kay Schenk <kay.sch...@gmail.com> >> > > > >> > > > > On Tue, Sep 25, 2012 at 7:51 AM, Shenfeng Liu <liush...@gmail.com >> > >> > > > wrote: >> > > > > >> > > > > > 2012/9/24 Keith N. McKenna <keith.mcke...@comcast.net> >> > > > > > >> > > > > > > Rob Weir wrote: >> > > > > > > >> > > > > > >> On Mon, Sep 24, 2012 at 8:59 AM, Keith N. McKenna >> > > > > > >> <keith.mcke...@comcast.net> wrote: >> > > > > > >> >> > > > > > >>> Rob Weir wrote: >> > > > > > >>> >> > > > > > >>>> >> > > > > > >>>> On Sun, Sep 23, 2012 at 10:13 AM, Shenfeng Liu < >> > > > liush...@gmail.com> >> > > > > > >>>> wrote: >> > > > > > >>>> >> > > > > > >>>>> >> > > > > > >>>>> Hi, all, >> > > > > > >>>>> After 3.4.1, we are focusing on preparation of the >> > > community >> > > > > > >>>>> graduation. >> > > > > > >>>>> But I still want to remind us to take some time to think >> > about >> > > > our >> > > > > > >>>>> future >> > > > > > >>>>> releases. >> > > > > > >>>>> >> > > > > > >>>>> We have the discussion early about what 3.5 and 4.0 >> > should >> > > > look >> > > > > > >>>>> like. >> > > > > > >>>>> If >> > > > > > >>>>> I remember correctly: >> > > > > > >>>>> (1) 3.5 should be more about fidelity, reliability, >> > performance >> > > > and >> > > > > > >>>>> translation, new platform support... >> > > > > > >>>>> (2) While 4.0, in addition to the same focuses as 3.5, >> should >> > > > also >> > > > > > add >> > > > > > >>>>> significant UX enhancements (e.g. sidebar, modern UI) and >> new >> > > > > values >> > > > > > >>>>> (e.g. >> > > > > > >>>>> Accessibility, social integration capability, enhanced >> > > installer, >> > > > > new >> > > > > > >>>>> features...). If we make good progress on those items at >> the >> > > same >> > > > > > time, >> > > > > > >>>>> we >> > > > > > >>>>> may consider to skip 3.5. >> > > > > > >>>>> (3) There are also more requirements (e.g. fixpack >> mechanism, >> > > > > > >>>>> simplifying >> > > > > > >>>>> the build structure, OOMXL export, smartArt...) we need >> to >> > put >> > > > > into >> > > > > > >>>>> our >> > > > > > >>>>> backlog and consider their priority. >> > > > > > >>>>> >> > > > > > >>>>> Even we don't need to discuss the solid plan now, but >> > there >> > > > are >> > > > > > >>>>> already a >> > > > > > >>>>> lot of development activities on the trunk. So I think we >> > need >> > > to >> > > > > > keep >> > > > > > >>>>> certain track on it. Though it may be too early to set a >> > target >> > > > > date >> > > > > > >>>>> for >> > > > > > >>>>> the next release, but it is important for us to tell more >> > about >> > > > > what >> > > > > > we >> > > > > > >>>>> think the next release should contain. >> > > > > > >>>>> >> > > > > > >>>>> So I'm suggesting the following: >> > > > > > >>>>> >> > > > > > >>>>> 1. Keep updating the current release planning wiki: >> > > > > > >>>>> - >> > > > > > >>>>> >> > > > > > >>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/** >> > > > > > >>>>> AOO+3.5+Release+Planning< >> > > > > > >> > > > > >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Planning >> > > > > > > >> > > > > > >>>>> - >> > > > > > >>>>> >> > > > > > >>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/** >> > > > > > >>>>> AOO+4.0+Release+Planning< >> > > > > > >> > > > > >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Planning >> > > > > > > >> > > > > > >>>>> I know it is a little confusing for 2 places to >> input. >> > But >> > > > > think >> > > > > > >>>>> about >> > > > > > >>>>> the scope we agreed above. You can input to the wiki that >> you >> > > > think >> > > > > > >>>>> your >> > > > > > >>>>> work belong to. I personally will monitor both wiki pages. >> > > > > > >>>>> >> > > > > > >>>>> 2. Figure out a better way to manage our release backlog. >> > e.g. >> > > > set >> > > > > > >>>>> Target >> > > > > > >>>>> Milestone to 3.5 or 4.0 in Bugzilla for what we >> recommended. >> > > > > > >>>>> >> > > > > > >>>>> 3. Deliver milestone builds to harvest our development >> > fruits. >> > > A >> > > > > > >>>>> milestone >> > > > > > >>>>> build is: >> > > > > > >>>>> (a) a development snapshot that contains the >> > > > > > >>>>> features/enhancements >> > > > > > >>>>> that implemented till now; >> > > > > > >>>>> (b) passed regression test to ensure no severe >> > defects; >> > > > > > >>>>> (c) announced on a development wiki; >> > > > > > >>>>> (d) with documents on the wiki for the list of >> > features >> > > > and >> > > > > > bug >> > > > > > >>>>> fixes >> > > > > > >>>>> in this milestone build (like a release notes). >> > > > > > >>>>> Since whatever 3.5 or 4.0 sounds to me like some >> thing >> > in >> > > > next >> > > > > > >>>>> year >> > > > > > >>>>> or >> > > > > > >>>>> at least close to the end of this year, milestone builds >> can >> > be >> > > > > light >> > > > > > >>>>> weigh >> > > > > > >>>>> on process to show our development progress, and give >> people >> > a >> > > > more >> > > > > > >>>>> clear >> > > > > > >>>>> view on how far are we to the next release. >> > > > > > >>>>> >> > > > > > >>>>> Looking forward every one's comments! >> > > > > > >>>>> >> > > > > > >>>>> >> > > > > > >>>> Maybe also start a "release notes" page on the wiki. >> > Whenever a >> > > > new >> > > > > > >>>> feature or important bug fix is added to the trunk also add >> > > > > something >> > > > > > >>>> to the release notes. If something can be show with a >> > "before >> > > > and >> > > > > > >>>> after" screen shot, include that. This might be easier >> than >> > > > waiting >> > > > > > >>>> until the end to prepare the release notes. >> > > > > > >>>> >> > > > > > >>>> -Rob >> > > > > > >>>> >> > > > > > >>>> >> > > > > > >>>>> - Simon >> > > > > > >>>>> >> > > > > > >>>> >> > > > > > >>>> >> > > > > > >>>> Rob; >> > > > > > >>> >> > > > > > >>> A Release Notes page already exists or 3.5 and one or 4.0 >> can >> > be >> > > > > easily >> > > > > > >>> added. The complication I see here is since we have not >> decided >> > > > > whether >> > > > > > >>> the >> > > > > > >>> next release will be 3.5 or 4.0 that would require adding >> it in >> > > two >> > > > > > >>> places. >> > > > > > >>> I see that as a lot of overhead at this point. >> > > > > > >>> >> > > > > > >>> >> > > > > > >> IMHO, the name is not so important. Everything in the trunk >> > goes >> > > > into >> > > > > > >> the next release. Nothing not in the trunk goes into the >> next >> > > > > > >> release. So if we want a wiki page that is called "Release >> > notes >> > > > for >> > > > > > >> AOO Target January 2013" then it would be sufficient. Just >> > > describe >> > > > > > >> significant changes there made in the trunk. Maybe in the >> end >> > we >> > > > call >> > > > > > >> it "Apache OpenOffice 2013", or "Apache OpenOffice >> Adventitious >> > > > > > >> Armadillo" or something like that. That decision can come >> > later. >> > > > > > >> >> > > > > > >> -Rob >> > > > > > >> >> > > > > > >> >> > > > > > > In that case lets use the existing 3.5 Release Notes as Armin >> has >> > > > > already >> > > > > > > put a number of entries in there the "name can be change to >> > protect >> > > > the >> > > > > > > innocent later". >> > > > > > > >> > > > > > >> > > > > > +1 to use the existing 3.5 Release Notes wiki. >> > > > > > >> > > > > > And I just made a query in BZ, for defects fixed after 3.4 (May >> 8), >> > > and >> > > > > > excluded (1) some Products as qa, www, (2) those Target >> Milestone >> > set >> > > > to >> > > > > > 3.4.1, and (3) Issue Type not in (DEFECT, FEATURE, ENHANCEMENT). >> > And >> > > I >> > > > > got >> > > > > > about 500 results. I picked some of them in the list and believe >> > > there >> > > > > are >> > > > > > still many items need to be taken out, e.g. those fixed 1 year >> ago, >> > > but >> > > > > > just validated recently. So I think I can quickly go through >> them, >> > > and >> > > > > for >> > > > > > those who are really fixed/implemented in trunk after 3.4 and >> not >> > in >> > > > > 3.4.1, >> > > > > > I will set the Target Milestone to AOO 3.5.0. And this list can >> be >> > a >> > > > base >> > > > > > for our release notes. How do you think? >> > > > > > >> > > > > > Another thing is that we need to define a test plan for the >> > milestone >> > > > > > build, which can be a lightweight regression test suite. The >> plan >> > can >> > > > be >> > > > > > published on a wiki, and executed against very milestone build. >> > > > > > I agree with Juergen that we should start as early as possible. >> > > While I >> > > > > > still hope to get the confirmation from our QE team, since IMO >> they >> > > are >> > > > > the >> > > > > > key to this plan. :) >> > > > > > >> > > > > > - Simon >> > > > > > >> > > > > >> > > > > Simon -- >> > > > > >> > > > > Great that you started this. Will all new features ( these seem >> to be >> > > all >> > > > > in Calc by the current 3.5 Release Planning doc), be given an >> issue >> > > > > assignment at some point to correspond to your BZ search filter? >> The >> > > one >> > > > > listed as i110133 doesn't seem to show up in either your >> "features" >> > or >> > > > > "all" filters you posted> I think it needs a target change (which >> I >> > > > didn't >> > > > > make). >> > > > > >> > > > > All this will be very very helpful for planning our next release. >> So, >> > > > thank >> > > > > you. >> > > > > >> > > > > >> > > > Kay, >> > > > The list on the wiki is out of date. So I update it and marked it >> > out. >> > > I >> > > > think i110133 is a defect that proposed to fix in 3.5, but further >> on >> > > there >> > > > is no update for this defect... >> > > > Per our lesson&learned from 3.4.1, a better way is to leverage >> > Bugzilla >> > > > query. So I created one: TargetTo350AllFix. Also, I put the link on >> 3.5 >> > > > wiki. >> > > > >> > > > - Simon >> > > > >> > > > >> > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > > >> > > > > > > Regards >> > > > > > > Keith >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> I could create a separate page as a sandbox where what you >> > > suggest >> > > > > > could >> > > > > > >>> be >> > > > > > >>> input, then when the release comes it is just a matter of >> > moving >> > > > the >> > > > > > data >> > > > > > >>> from the sandbox into the formal Release Notes page. >> > > > > > >>> >> > > > > > >>> Regards >> > > > > > >>> Keith >> > > > > > >>> >> > > > > > >>> >> > > > > > >> >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > >> > > > > >> > > > >> > > >> > >> ---------------------------------------------------------------------------------------- >> > > > > MzK >> > > > > >> > > > > "Just 'cause you got the monkey off your back >> > > > > doesn't mean the circus has left town." >> > > > > -- George Carlin >> > > > > >> > > > >> > > >> > > >> > > >> > > -- >> > > >> > > >> > > Thanks & Best Regards, Yan Ji >> > > >> > >> > >
