Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of anton.luht@gmail.com designates
 66.249.92.170 as permitted sender)
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=G/wza0zlRCtd3FS6TQ0/ESHdDHIV8TtWua9EvFi4tlPPhz0SBNVSXPcjx/vu93nFA7vyg074anQ2ana4X4TfaS6QnJfIqiwhBERN/78z30nwD6QwknR/IIuGibyeOgRdh4ud/BMW3aTZRVpfSRRBjMh5ZGdv5ivnUV1cFRlx2us=
Message-ID: <ddda44ee0606270423p72ef7d9dgba7ed1a9c541a61c@mail.gmail.com>
Date: Tue, 27 Jun 2006 15:23:53 +0400
From: "Anton Luht" <anton.luht@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM] Integration checks (was building from svn on FC5)
In-Reply-To: <7273946b0606270312t5b862b47p5cd726dac672b0d9@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: <6928c5160606231100k51affc3bt23358a4b667319ac@mail.gmail.com>
	 <c3755b3a0606231123j3cc9ad32sdf78db6d627028c9@mail.gmail.com>
	 <449FFCB2.1000906@Intel.com>
	 <7273946b0606270312t5b862b47p5cd726dac672b0d9@mail.gmail.com>

Good day,

Anyway it seems that creating an automated Eclipse scenario as
described by Salikh will be useful. I'll try to create the scenario,
corresponding build target and file a JIRA issue with patch for the
new functionality.

On 6/27/06, Vladimir Ivanov <ivavladimir@gmail.com> wrote:
> Seems, it is not so easy to define the proper test set...
> Let's define target to run the integration test. It may be:
>  1) we want to be sure that all were integrated correctly?
>  2) or we want to guaranty the 'product quality' for build?
>  3) some other?
>
> If target is 1) than we should run minimal tests set (seems, classlib unit
> tests over tested VM will enough) on one platform.
> If target is 2) than each developer should run all known/defined tests over
> all platforms. Seems, is no time for development any more. Everyone will do
> the release engineering (RE) work.
>
> So we have 2 questions here:
> 1) the small list of integration test should be defined. It may be subset of
> API unit tests collected as 1 or 2 tests from each API area just to be sure
> that all things were integrated successfully.
> 2) the RE procedure should be defined. Who is responsible to build the HDK
> and place it to download page? What tests should be run before it? How often
> it should be doing?
> It is not so obvious as 1). The procedure may be defined, for example, as:
>  - one of committers prepare binary form of HDK and test it on one platform.
>
>  - if all tests passed he placed it to download somewhere and
>  - other people test it on other platform.
>  - if all tests passed the binaries are promoted and placed to the
> 'official' download page.
>
>  Thanks, Vladimir
>
> PS. To run some scenario tests actually not integration but functional
> testing.
>
> On 6/26/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> >
> > Alexey Petrenko wrote:
> > > Some checks before commits are defenetly good...
> > >
> > > 2006/6/23, Andrey Chernyshev < a.y.chernyshev@gmail.com>:
> > >> We may probably also need to define the list of
> > >> platforms/configurations covered by this procedure.
> > > I'm not sure that I get your idea correctly.
> > > Do you suggest to ask every developer to make some checks on different
> > > platforms and software configurations?
> > > If so... Yes, it is good for product stability.
> > > But it will be nearly impossible because very small number of
> > > developers have access to different platforms and software
> > > configurations...
> >
> > First and foremost question is *what* to run as integration tests,
> > rather than on what platforms. I think we need to define what use cases
> > we care for in the form of integration tests.
> > The more conveniently the integration tests are packaged, the higher is
> > the probability of anyone running them.
> > The good example is the "smoke tests" included with DRLVM: they can be
> > built and run
> > with a single command 'build.bat test' ('build.sh test' on Linux).
> >
> > Once the integration test set is defined, we can think of platform
> > coverage.
> > BuildBot [1] could be the way to interested parties to contribute CPU
> > cycles
> > to verify Harmony quality.
> >
> > [1] http://buildbot.sourceforge.net/
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>


-- 
Regards,
Anton Luht,
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org