Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of alexei.zakharov@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=GQiKKhcQ9k+jMJGqdjQQBeAH2Gf0kYk3m+GvKowuX9nE4w+huAadt6zGsJmYdEa+xbkFjxdOHiQdttC5ZxTDiYdw0mMOuFNREapm7fdNSOqjkjxIGkvinbQb/8TVflQOD0vPtdxtbijdcHu+R/aMVxGkJTjVAs91mZmDokIwepM=
Message-ID: <2c9597b90704130453u286fe92hdaeb68d6acd6c3b5@mail.gmail.com>
Date: Fri, 13 Apr 2007 15:53:23 +0400
From: "Alexei Zakharov" <alexei.zakharov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general] Discussion: how to keep up stability and fast progress
 all together?
In-Reply-To: <c3755b3a0704040149n1a8e6ea8r93fbf5dd6d8c39c9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6e47b64f0703300131j291450c8if09efc59914c9076@mail.gmail.com>
	 <460D1B1F.5000006@gmail.com>
	 <6e47b64f0704020210j3b5ac8c9rb81d5871381dd4f@mail.gmail.com>
	 <7273946b0704022036l4057dc02gbeed4697e4970e9d@mail.gmail.com>
	 <c3755b3a0704040031x24368a3fnba75430d141958a0@mail.gmail.com>
	 <6e47b64f0704040139q19e6d481wecec42fb979af8be@mail.gmail.com>
	 <c3755b3a0704040149n1a8e6ea8r93fbf5dd6d8c39c9@mail.gmail.com>

> jEdit?
> But I'm not sure that it works ok on current class library :)

I've tried to run jEdit on Harmony recently. I was able to start it on
IBM VME only - it fails to start on JITed version of DRLVM and startup
takes tooo long in DRLVM's interpreter mode (however, it starts).  But
even on IBM VME it is not able to work longer than about 10 minutes.

Regards,

2007/4/4, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
> 2007/4/4, Stepan Mishura <stepan.mishura@gmail.com>:
> > On 4/4/07, Alexey Petrenko wrote:
> > <SNIP>
> > > > > I'd like to propose the next approach that may help us to know about
> > > > > instabilities: develop (or take existing one, for example, Eclipse
> > > > > hello world) a scenario for testing stability and configure CC to run
> > > > > it at all times. The stability scenario must be the only one scenario
> > > > > for CC; it must be short (no longer then an hour), test JRE in stress
> > > > > conditions and cover most of functionality. If the scenario fails then
> > > > > all newly committed updates are subject for investigation and fix (or
> > > > > rollback).
> > > > Actually, I prefer something without GUI
> > > I do not think that remove GUI testing from CC and other stability
> > > testing is a good way to go. Because awt and swing modules are really
> > > big and complicated pieces of code.
> > >
> >
> > Sorry for the confusion - I agree that we should continue running
> > AWT/Swing tests under CC. But we are talking about scenario that can
> > be used for testing stability in terms of race conditions. The first
> > scenario that spread in my mind was Eclipse hello world testing
> > scenario: it is quite short, verifies core functionality and so on.
> > But Vladimir claimed that there might be some issues related to GUI
> > testing and we may have a number of 'false alarms'.
> In fact Eclipse does not use awt and swing at all so it can not be
> used as a test for these modules.
>
>
> > BTW, do you have any scenario in mind that can be used a stability
> > criteria (of cause in terms of race conditions)?
> jEdit?
> But I'm not sure that it works ok on current class library :)
>
> SY, Alexey
>
> > > > or at least without using
> > > > special 'GUI testing" tools. It should improve quality of this testing
> > > > (than less tools than more predictable results :)) Current "Eclipse
> > > > hello world" scenario based on the AutoIT for Win and X11GuiTest for
> > > > Linux platform. Also we have this scenario based on API calls which
> > > > should emulate GUI scenario. From these 2 approaches I prefer second
> > > > to minimize 'false alarms'. Or may be some other scenarios (non-GUI)?
> > > >
> > > >  Thanks, Vladimir
> > > >
> > > >
> > > > >
> > > > > Thought? Objections?
> > > > >
> > > > > Thanks,
> > > > > Stepan.
> > > > >
> > > > > > I read the discussion on naming, and M1, M2, ... is fine by me.  How
> > > > > > about we pick a proposed date for Apache Harmony M1?


-- 
Alexei Zakharov,
Intel ESSD