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 6C62ED897 for ; Thu, 30 Aug 2012 07:51:56 +0000 (UTC) Received: (qmail 44684 invoked by uid 500); 30 Aug 2012 07:51:55 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 44361 invoked by uid 500); 30 Aug 2012 07:51:55 -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 44317 invoked by uid 99); 30 Aug 2012 07:51:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2012 07:51:53 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of awf.aoo@gmail.com designates 209.85.214.47 as permitted sender) Received: from [209.85.214.47] (HELO mail-bk0-f47.google.com) (209.85.214.47) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2012 07:51:44 +0000 Received: by bkcik5 with SMTP id ik5so658873bkc.6 for ; Thu, 30 Aug 2012 00:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=hf7WR06QgTUuJNJRPx9DfxM7WhcTi/VEm4axiYkg2GM=; b=n0IOSqDjHlCifjflXbXhg6lYijStSN9S3zoMUclXOcU/o7jZctWGObquXWRVNwzoBP xh/vgxuzEh2Kc+6U5P//JoJhmOE9rN9p6NCdaSIvn+ig4EHxcdgbUqpyf2ClZi4j9jEU AITLmaEZ0ygPSsKC2NJ35DZGsQztwlfmfBEtVclr+XoOglEpNYUTsoW/4PilqgICjfYk IHiBb+QgDA/x/8w7KY5ds5z1VB6Ku28yaGAVJeFmoXnk4aX0W/guX/xveWPUjUlUC4Cw xfOLCdUsRQelfTkE5iR2zlWQp17VyK7i9Xvq+W9CfaVUcZCQN4eImizQ0f+8RfP0gKel WKaw== Received: by 10.204.136.216 with SMTP id s24mr2251682bkt.137.1346313083588; Thu, 30 Aug 2012 00:51:23 -0700 (PDT) Received: from [9.155.131.75] (deibp9eh1--blueice2n2.emea.ibm.com. [195.212.29.172]) by mx.google.com with ESMTPS id n5sm412388bkv.14.2012.08.30.00.51.22 (version=SSLv3 cipher=OTHER); Thu, 30 Aug 2012 00:51:22 -0700 (PDT) Message-ID: <503F1B7A.5020204@googlemail.com> Date: Thu, 30 Aug 2012 09:51:22 +0200 From: Andre Fischer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ooo-dev@incubator.apache.org Subject: Re: 27MB odt file in svn References: <503E1EA0.80801@googlemail.com> <503E356D.2070307@googlemail.com> <503E5E71.5090606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 30.08.2012 04:09, Shenfeng Liu wrote: > +1 for test data and test script in a separated tree. Test documents should > never be distributed together with product code. Only the sample documents > in tutorials should. > Another advantage for a separated QE tree is that a volunteer can download > any AOO build and run the same test suite from the QE tree again and again, > a easy way of regression and even automation. Good idea, a third use case: use pre-built office and only the test/ source code. > A complex situation maybe the UT by developer that calls internal > functions. Sometimes developers like to write UT code together with the > product code. But will a sample document be used in UT? Even when we move the testing stuff one level higher to be on the same level as main/ and ext_libraries/ then an SVN checkout still puts it on your local disk. The advantage of that move would be that a) you can avoid checking out test/ and b) it becomes easier to avoid including test/ in the source release. Are there any volunteers for this move? I would do it myself but I am on vacation for the next three weeks. -Andre > > - Simon > > > 2012/8/30 Dave Fisher > >> >> On Aug 29, 2012, at 11:24 AM, Kay Schenk wrote: >> >>> >>> >>> On 08/29/2012 10:51 AM, Rob Weir wrote: >>>> On Wed, Aug 29, 2012 at 11:29 AM, Andre Fischer >> wrote: >>>>> On 29.08.2012 16:02, Rob Weir wrote: >>>>>> >>>>>> On Wed, Aug 29, 2012 at 9:52 AM, Andre Fischer >> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I just saw that we have now two new binary files in the test/ module. >>>>>>> >>>>>>> main/test/testgui/data/svt/complex.ods has a size of 9 424 385 Bytes >> and >>>>>>> main/test/testgui/data/svt/complex.odt has a size of 27 175 936 >> Bytes. >>>>>>> >>>>>>> I wonder if SVN is really the best place for files that large. >>>>>>> >>>>>>> I also don't think that these files should be part of the source >> release. >>>>>>> But what else would have to be removed that depends on these files? >>>>>>> >>>>>>> Any thoughts? >>>>>>> >>>>>> >>>>>> Something to keep in mind is that we'll probably end up with a large >>>>>> number of test documents, 200+ MB. Not all of them will be large. >>>>>> But if we want to have good test coverage then we'll need test >>>>>> documents to cover all areas, for ODF, MS Binaries and OOXML. So this >>>>>> will grow, over time, to a large test set. >>>>>> >>>>>> This leads to four questions: >>>>>> >>>>>> 1) Should we be testing large/complex documents? >>>>>> >>>>>> I think the answer is "yes". >>>>> >>>>> >>>>> Agreed. >>>>> >>>>> >>>>>> >>>>>> 2) Should such test documents be in SVN? >>>>>> >>>>>> I think they should. >>>>> >>>>> >>>>> Agreed. >>>>> >>>>> >>>>>> >>>>>> 3) Should these documents be in the same source tree with the rest of >>>>>> the code that is downloaded by default for a build? >>>>>> >>>>>> Maybe not. Unless they are needed for a smoke test that should be run >>>>>> by every developer. But if not, maybe they should be stored in its >>>>>> own tree, like ooo/test/trunk or something like that. >>>>>> >>>>>> 4) Should these documents be included in the source distribution? >>>>>> >>>>>> Probably depends on the answer to question 3. Maybe, maybe not. Or >>>>>> maybe we have a separate source distribution artifact only for >>>>>> test-related files? >>>>> >>>>> >>>>> >>>>> My personal opinion is no. I believe that the use case for >> downloading and >>>>> building the source release is different from the use case for cloning >> the >>>>> SVN repository. I would expect the source release to be used for >> building >>>>> AOO, maybe do a simple test to verify that building was successful, >> and then >>>>> delete the source code. >>>>> >>>> >>>> OK. That is a useful distinction: building versus developing. >> >> I think Building versus QA - both are developing. >> >>>> >>>>> If I want to start developing then I would choose SVN. Complex tests >> would >>>>> help me to avoid new errors. >>>>> >>>>> I don't see the need for complex tests when my goal is not developing. >> Lack >>>>> of trust that we did not run the tests on the released code? >>>>> >>>>> But, of course I can be wrong (and often are :-). >>>>> >>>> >>>> If we follow that logic, then we might still store the test data and >>>> test code in SVN, but in its own tree, e.g., /ooo/test/trunk. >>>> >>>> This also preserves the option of us having a "test source" artifact >>>> in a future release, if we wanted. >>>> >>>> -Rob >>> >>> +1, this seems like a good compromise >>> >>> I don' think the "test" cases should be in the same tree as source. >> >> Agreed. >> >>> >>> No use overloading developers who simply want to build and make >> modifications. >> >> Source is required as an Open Source release. (we should all understand >> that.) >> >> QA / test is "optional" but quite important. It should be separate and we >> can include a "QA" package as one of our convenience binaries during a >> release. >> >> Regards, >> Dave >> >>> >>> >>>> >>>>> -Andre >>>>> >>>>>> >>>>>> -Rob >>>>>> >>>>>> >>>>>>> Regards, >>>>>>> Andre >>>>> >>>>> >>> >>> -- >>> ------------------------------------------------------------------------ >>> MzK >>> >>> "As a child my family's menu consisted of two choices: >>> take it or leave it. " >>> -- Buddy Hackett >> >> >