Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 41910 invoked from network); 16 Apr 2008 11:27:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Apr 2008 11:27:50 -0000 Received: (qmail 26471 invoked by uid 500); 16 Apr 2008 11:27:50 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 26440 invoked by uid 500); 16 Apr 2008 11:27:50 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 26431 invoked by uid 99); 16 Apr 2008 11:27:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Apr 2008 04:27:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alexey.v.varlamov@gmail.com designates 74.125.46.158 as permitted sender) Received: from [74.125.46.158] (HELO yw-out-1718.google.com) (74.125.46.158) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Apr 2008 11:27:07 +0000 Received: by yw-out-1718.google.com with SMTP id 4so1183294ywq.0 for ; Wed, 16 Apr 2008 04:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MhU6Uw146qS0AAUYIEPAxGp6RHb2rJ0JIi5NpKFTF+Y=; b=qxTNmaTeDKRIHXq4z52IJQkIPnxYxaX3cxNtDY9KQSuUh3Rkf+Qc/1aL8yx+xXnA3xTilHxNQV4i6vc4ceHVYPcGxjvuPSJUkyKdNKkCgHjTrKMD8P2XdN1PjvHFHVCPyQFI/s3BtTokvGVNIARGPoTRHCbRCtJWsVItKBrJYbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=x9WBeLslMUZGli3FKlRzOp7n2VMiw7etVggzNhfmy+bc1PvMDhBNAclxm1XVX7L3WlkHsy/2o26IpLGhnwowTa2wNWtkglDj/43RM6AIxfC8ytjcRuFn1tCA5KikcjCUDPBBvwUs2RX22JQlys5PnB1q/OgJqwFHrPynaPt8h6s= Received: by 10.151.156.2 with SMTP id i2mr8971795ybo.177.1208345234198; Wed, 16 Apr 2008 04:27:14 -0700 (PDT) Received: by 10.150.143.1 with HTTP; Wed, 16 Apr 2008 04:27:14 -0700 (PDT) Message-ID: Date: Wed, 16 Apr 2008 18:27:14 +0700 From: "Alexey Varlamov" To: dev@harmony.apache.org Subject: Re: [testing] How long we should keep test results for millstones? In-Reply-To: <4805C923.9090507@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6e47b64f0804160024h277330d7m5ac42ec2670709e5@mail.gmail.com> <4805B083.1030901@gmail.com> <4805C6C0.9020207@Stolsvik.com> <4805C923.9090507@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org 2008/4/16, Tim Ellison : > Endre St=F8lsvik wrote: > > Tim Ellison wrote: > > > > > Alexey Petrenko wrote: > > > > > > > I do not think that we are really need any other test results then > Mn-1 > > > > > > > > > > I agree, keep the last Milestone for regression checking, and if you > really want to be nostalgic keep the last two, but anything beyond that i= s > unnecessary. > > > > > > > Why not keep everything? I guess the space it takes isn't quite the iss= ue? > > > > You can more easily see trends in the data with more than two datapoint= s, > uncovering more subtle regressions etc. And it may even have a tint of "f= un" > to it, seeing how much better it became over time, for each milestone, > revision and version. > > > > (Of course, these data can be recreated by checking out the older > milestones and run the tests again... but ..) > > > > If space is not an issue then yes, we might as well keep them around, but= we > share finite resources with the rest of Apache so I think we should only > keep what we think we will need. > > If somebody has an idea to use it for archaeological purposes then fine. AFAIR number of files was the main issue, though space may become an issue too in some future :) Kinda compromise is possible, to compress older data and provide a link to the bulk archive if someone needs detais. Summary pages do not eat much anyway. -- Alexey > > Regards, > Tim >