Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B6DB8902A for ; Mon, 8 Oct 2012 19:06:31 +0000 (UTC) Received: (qmail 48715 invoked by uid 500); 8 Oct 2012 19:06:31 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 48643 invoked by uid 500); 8 Oct 2012 19:06:31 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 48635 invoked by uid 99); 8 Oct 2012 19:06:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Oct 2012 19:06:31 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of marcus.mail@wtnet.de designates 213.209.103.15 as permitted sender) Received: from [213.209.103.15] (HELO smtp4.wtnet.de) (213.209.103.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Oct 2012 19:06:23 +0000 X-WT-Originating-IP: 84.46.110.107 Received: from f9.linux (pop8-1636.catv.wtnet.de [84.46.110.107]) (authenticated bits=0) by smtp4.wtnet.de (8.14.4/8.14.4) with ESMTP id q98J63XL023853 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 8 Oct 2012 21:06:03 +0200 Message-ID: <50732418.1090502@wtnet.de> Date: Mon, 08 Oct 2012 21:06:00 +0200 From: "Marcus (OOo)" User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: ooo-dev@incubator.apache.org Subject: Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack, milestone build...) References: <5072E9FB.2000107@gmail.com> In-Reply-To: <5072E9FB.2000107@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Am 10/08/2012 04:58 PM, schrieb J�rgen Schmidt: > On 10/8/12 3:36 PM, Shenfeng Liu wrote: >> 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. > > thanks for picking it up again, we should definitely start with snapshot > builds asap > >> 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. > > The build bots are still not build the same as we do for the binary > releases (please correct me if I am wrong). Means as long as we don't > have build bots which are building with the same configuration we should > provide the builds manually in the same way we did it for the release. > > @Ariel, would that be ok for you fro now until we have a better solution? > > I will take care of Windows and MacOS. > > >> (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. > > We should include the languages that we have released and add all > languages where we notice active volunteers who help us to support these > further languages (eg. Polish, Danish, Scots Gaelic, ...) > > >> (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? > > I am not sure if understand you correct. The revision is a unique > identifier and makes it clear what went in the snapshot. We probably > upload the builds not all on the same day. Means I am not sure how a > date can help here. I also wouldn't rely on a date value, even if it's looking right on the fisrt view. The revision number is what referenced everywhere (SVN, BZ). So, whenthe developer asks you "In which build have you seen this or that?" then you can tell her/him just the rev number. >> 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. > > 1 + 2 are good ideas to keep the info up-to-date and to reduce the work > later on short in front of the release. > >> (2) a web page to announce this milestone build. > > mmh, when we want to promote the dev builds more we should consider the > use of the mirrors. But this means we have to do more "release" > preparation. I am not sure if we can and want manage this additional > overhead at the moment. But I am open and we should check what's > necessary to achieve this. For the normal testing IMHO we can rely on an en-US full build and langpacks only for all other languages. For special issues (e.g., fixes for the installer and system integration) we could build special install files on demand. BTW: I think it's clear that - if we all agree that we want it - I can support this process with updating the download webpages to offer the dev builds here instead (or additionally) of the Wiki. ;-) Marcus >> 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 >> >>> 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 >>> >>>> 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 wrote: >>>> >>>>> 2012/9/26 Ji Yan >>>>> >>>>>> 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 >>>>>> >>>>>>> 2012/9/26 Kay Schenk >>>>>>> >>>>>>>> On Tue, Sep 25, 2012 at 7:51 AM, Shenfeng Liu>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>>> 2012/9/24 Keith N. McKenna >>>>>>>>> >>>>>>>>>> Rob Weir wrote: >>>>>>>>>> >>>>>>>>>>> On Mon, Sep 24, 2012 at 8:59 AM, Keith N. McKenna >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Rob Weir wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Sep 23, 2012 at 10:13 AM, Shenfeng Liu< >>>>>>> liushenf@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.