harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [general] define pre-commit testing configs to gain the stability
Date Fri, 06 Oct 2006 18:27:13 GMT


Pavel Ozhdikhin wrote:
> What would you do if you need to commit a patch to some Linux-specific
> code in VM?

Ask someone w/ a linux box to check it.

> The commit criteria my be either as simple as a list of configs or
> have also some exclusions. For example, there is no much sense to test
> on Linux a patch for a source file which is not even compiled on
> Windows.
> 
> On 10/7/06, Nathan Beyer <nbeyer@gmail.com> wrote:
>> I only have Windows/MSVC2003/IA32, if you're looking for anecdotal 
>> evidence.
>>
>> On 10/6/06, Pavel Ozhdikhin <pavel.ozhdikhin@gmail.com> wrote:
>> > Alexey,
>> >
>> > No, I'm not sure the committers have all the configurations. I think
>> > most of all have Windows and Linux IA32, but I doubt all of them have
>> > EM64T. This is indeed the problem and I hope together we will find the
>> > solution. For example, we may not require classlib commits to be
>> > tested on EM64T for now, or check if Apache has machines for testing,
>> > or we'll have a magic tool which will run EM64T tests for all
>> > committers on some hidden machine etc. If finally we realize that it's
>> > impossible to require EM64T testing at this time, we can delay this
>> > particular config, but regarding remaining criteria I think we can
>> > avoid many problems using primary target configs.
>> >
>> > Thanks,
>> > Pavel
>> >
>> >
>> >
>> > On 10/6/06, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
>> > > Pavel,
>> > >
>> > > Your idea has sence. But... Are you sure that all the committers has
>> > > all the mentioned configurations?
>> > >
>> > > SY, Alexey
>> > >
>> > > 2006/10/6, Pavel Ozhdikhin <pavel.ozhdikhin@gmail.com>:
>> > > > Hello all,
>> > > >
>> > > > This thread is about a way to improve stability in the 
>> environment of
>> > > > growing patch flow in Harmony. Originally I though about DRLVM 
>> issues
>> > > > but this may be helpful for classlib too.
>> > > >
>> > > > Currenly, before committing a patch a committer checks it on his
>> > > > favorite configurations (I mean architecture, OS and compiler 
>> first of
>> > > > all). Another committer checks another patch on a different set of
>> > > > configurations. As a result, though both patches are tested, 
>> there is
>> > > > no guarantee that they will work together on any configuration.
>> > > >
>> > > > If we agree on common testing configs we can make sure the Harmony
>> > > > will be stable on at least this set of configurations. This does 
>> not
>> > > > mean we won't fix problems on other configurations. The goal is to
>> > > > gain and maintain general stability.
>> > > >
>> > > > Another benefit would be in faster adoption of patches. If
>> > > > contributors could check their patches on the same configs as the
>> > > > committers do, there would be less likely a particular patch is
>> > > > rejected.
>> > > >
>> > > > I propose to work out a set of configs the committers will use to
>> > > > check patches before committing them to SVN. We can start with a 
>> few
>> > > > configs defining the platform, OS familly and the compiler used. 
>> When
>> > > > we are sure the Harmony is stable we can add more 
>> configurations. IMO,
>> > > > it would be reasonable to start with 3 configurations - one
>> > > > configuration for each supported platform, for example:
>> > > >
>> > > > - Windows / IA32 / MSVS .NET 2003 / release
>> > > > - Linux / IA32 / GCC 4.0.3 / release
>> > > > - Linux / EM64T / GCC 4.0.3 / release
>> > > >
>> > > > There may be a contrary point - let's everyone use it's own 
>> platform -
>> > > > such way we'll discover bugs earlier. I think this might work 
>> good in
>> > > > a smaller project. The Harmony is quite a big child already and 
>> trying
>> > > > to kill all the birds we may chase them for ages.
>> > > >
>> > > > I'd be happy if we converge on the set of our primary target 
>> configs here.
>> > > >
>> > > > Thank you
>> > > > Pavel Ozhdikhin
>> > > >
>> > > > 
>> ---------------------------------------------------------------------
>> > > > 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
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Alexey A. Petrenko
>> > > 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
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
> 
> ---------------------------------------------------------------------
> 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
> 

---------------------------------------------------------------------
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


Mime
View raw message