From dev-return-21912-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Mon Dec 18 12:30:05 2006 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 28541 invoked from network); 18 Dec 2006 12:30:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Dec 2006 12:30:05 -0000 Received: (qmail 88278 invoked by uid 500); 18 Dec 2006 12:30:10 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 88065 invoked by uid 500); 18 Dec 2006 12:30:09 -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 88056 invoked by uid 99); 18 Dec 2006 12:30:09 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Dec 2006 04:30:09 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of alexey.a.petrenko@gmail.com designates 66.249.92.173 as permitted sender) Received: from [66.249.92.173] (HELO ug-out-1314.google.com) (66.249.92.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Dec 2006 04:29:55 -0800 Received: by ug-out-1314.google.com with SMTP id z36so1194594uge for ; Mon, 18 Dec 2006 04:29:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YT7UZrdl3lnmNE5ZFcez7LiwhdJb5n4m4wSbtKMoKtjSqRb+zYluiBRl0doXGMZUYMmFilqjHDepcxkllO1dXYgC6ucKADbz2hVQ0YjUSb3xQ3xQOCBcnLSNd3OW+ewjfmAJFoBN97vEa6Zsyvrxss5+KPYGvZrBOarQ90CvL1w= Received: by 10.78.204.20 with SMTP id b20mr2918401hug.1166444971571; Mon, 18 Dec 2006 04:29:31 -0800 (PST) Received: by 10.78.107.15 with HTTP; Mon, 18 Dec 2006 04:29:31 -0800 (PST) Message-ID: Date: Mon, 18 Dec 2006 15:29:31 +0300 From: "Alexey Petrenko" To: dev@harmony.apache.org Subject: Re: [general] aiming no regression In-Reply-To: <906dd82e0612180421g41c7a800k5e79e58639b905d4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <906dd82e0611302119r7ae3150ewf2c918474ab8f302@mail.gmail.com> <45703C81.9070607@pobox.com> <906dd82e0612180421g41c7a800k5e79e58639b905d4@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org I agree with "revert and continue" approach. SY, Alexey 2006/12/18, Mikhail Loenko : > I'd like to bring it back... > > 2006/12/1, Geir Magnusson Jr. : > > > > > > Mikhail Loenko wrote: > > > seems like we need to refersh our agreements aiming better stability. > > > There are questions to discuss and decision to be made. > > > > > > > > > 1) We have exclude list for each paltform and for two VMs. We have > > > discussed a separation of the common part but did not reach any > > > agreement. To make fixing VM- and platform-specific bugs easier I > > > suggest that we agree to separate a > > > common part. > > > > I thought we agreed. Either way, this is a side issue wrt regression. > > > > > > > > > > > 2) Usually committers check the classlib patches on J9 and then > > > commit. At this point checking the patches on DRLVM is not that > > > convinient so at the moment we don't ask committers to do classlib > > > pre-commit testing on DRLVM. > > > > Yes, and we're getting near the time to switch that. People have the > > freedom to do what they want, but we need to get this happening > > regularly. I'll do something to make it easier for this to happen - > > I'll make a "drop-n-go" snapshot of DRLVM so it can be dropped directly > > into classlib's deploy/jdk/jre/bin as /default. > > > > The only remaining issue that I can see is the infernal hythread.so > > problem. Would we solve that simply by renaming our hythread.so in DRLVM? > > > > > > > > > > > 3) CC should report each time state changes (pass to fail or fail to > > > pass) and each > > > time failure reason changed. Failure reason may change because some > > > committers could miss failure notifiaction and do commit. Until we are > > > able to say that failure reason has changed we report each failure and > > > only the first success. > > > > Sure. > > > > > > > > > > > 4) We have cruise controls running classlibrary tests on DRLVM. We > > > need to decide what will we do when DRLVM+Classlib cruise control > > > reports failure. > > > > Stop and fix the problem. Is there really a question here? I agree > > Yes, there is a question here. "Stop and fix" includes "discuss". But > as we now know discussion may take several days. And while some people > discuss what the problem is other people can't proceed with > development and patch > intagration. > > To have better pace and better CC up-time we need something else but not > just "stop and fix". I suggest "revert and continue" > > Comments? > > Thanks, > Mikhail > > > > with Rana and Tim - we need to find a balance, and I think that with > > continued social awareness like this, we'll do better. We can always > > revisit if things don't go well. > > > > > IMHO It's pretty obvious that before we have found a commit causing that > > > we stop further commits. > > > > > > > > > 5) If the cause of failure is DRLVM commit than it's pretty obvious > > > that we roll it back. > > > > > > > > > 6) If the cause is Classlib test commit than we check wether the test > > > is valid (e.g. run it on RI) and not VM-specific. If the test is valid > > > we exclude it in DRLVM exclude list. If the test is invalid or > > > VM-specific we roll it back or fix ASAP. > > > > I don't completely agree, because it supports the idea that our tests > > must run on the RI, which can't be true for all classlib tests, and > > results in things like "isHarmony()". > > > > We have two VMs to work with - one, a high-quality production grade VM > > (j9) and the other a soon-to-be high-quality production grade VM (DRLVM) :) > > > > I suggest that a classlib failure is tested on both and then figure out > > what's the right answer, using the RI if possible. > > > > > > > > > > > 7) If the cause is a Classlib commit then this commit either reveals > > > existing problem in DRLVM or introduces a regression. I don't have > > > strong preferences here whether we'd better exclude the test or roll > > > the commit back > > > > I think that it's fine to exclude the test *if* the commit identifies > > the problem and someone takes on the task of solving the problem > > immediately, in the interest of keeping things moving. > > > > > > > > > > > 8) We may also advise that committers don't commit changes just before > > > going sleep or vacation. They should wait reasonable time to receive > > > CC failure report if any. The problem is "reasonable time" is hardly > > > predictable > > > > > > Comments? > > > > > > Thanks, > > > Mikhail > > >