You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Pavel Ozhdikhin <pa...@gmail.com> on 2006/10/06 18:30:25 UTC
[general] define pre-commit testing configs to gain the stability
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Rana Dasgupta wrote:
> On 10/6/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>>
>>
>>
>> >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.
>>
>>
>> >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
>>
>> We need to check both release and debug builds...the binaries and timing
> characteristics are too different. At this immediate stage of the
> project, I
> would suggest leaving out EM64T as part of mandatory testing( unless it is
> EM64T specific functionality, eg., codegen ). Too few contributors and
> committers have access to it. We are not yet at a stage where we can make
> this mandatory.
I have a machine now :) I will be EM64T-ing all the live-long day!
>
> If possible all submissions should be tested( by submitters ) on all the
> combinations identified . It is actually more urgent for submitters to do
> this. We should stop patches by email.
We don't really accept them.
> Also, at this point, it is an honor
> system, we can't attach 6 before and after test logs to each JIRA
> submission. The committer could randomly check on one or more combination,
> ...the more the better obviously.
I think that just having a submitter note which platforms have been
tested is good. Having others test and note their results is good too.
Best is getting community CI systems set up. That EM64T system will be
for that, and I'll have a linux 32 bit machine also doing it.
>
> In some cases, submissions will be platform specific ( eg., very new code
> like GC V5, platform specific bug fixes or a simple case of developer not
> having all the machines ). I would leave these to the committers'
> discretion.
>
> Thanks.
>
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Rana Dasgupta wrote:
>> We need to check both release and debug builds...the binaries and timing
>> characteristics are too different. At this immediate stage of the
>> project, I
>> would suggest leaving out EM64T as part of mandatory testing( unless it is
>> EM64T specific functionality, eg., codegen ). Too few contributors and
>> committers have access to it. We are not yet at a stage where we can make
>> this mandatory.
>>
>> If possible all submissions should be tested( by submitters ) on all the
>> combinations identified . It is actually more urgent for submitters to do
>> this. We should stop patches by email. Also, at this point, it is an honor
>> system, we can't attach 6 before and after test logs to each JIRA
>> submission. The committer could randomly check on one or more combination,
>> ...the more the better obviously.
>>
>> In some cases, submissions will be platform specific ( eg., very new code
>> like GC V5, platform specific bug fixes or a simple case of developer not
>> having all the machines ). I would leave these to the committers'
>> discretion.
>
> Mandating that patches are pre-tested on a wide variety of machines is
> not conducive to building a broad community of contributors since very
> few people have access to all the machines and configurations we are
> interested in. I'd much prefer that we work optimistically and have
> lots of people regularly building and testing the code to get the
> broadest possible coverage. We can backtrack if problems arise.
Well, exactly, sorta.
While I think that we can't mandate, I'd like to see if we can get a
community 'meme' going where people w/ different configs try patches and
just report into the JIRA that things worked... would give the
committer that handles the patch a bit more confidence...
geir
>
> Regards,
> Tim
>
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/11/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
>
> A better solution would be if he sends us a patch which fixes his problem.
> It
> is open source, isn't it? If it doesn't work for you, fix it yourself. The
> more people care about some platform or configuration, the better it
> works.
>
May be the best way is to join the both solutions in this case?
So we will fix bugs on every platforms we can reach
plus provide a priviliged support (I mean the stability of JRE) for
some certain "builds from the box": example WindowsXP, SUSE10...
The quality and stability is often more attractive feature than performance
for Java users.
So we must do something to beat the RI here.
--
Mikhail Fursov
Re: [general] define pre-commit testing configs to gain the stability
Posted by Gregory Shimansky <gs...@gmail.com>.
On Tuesday 10 October 2006 17:28 Mikhail Fursov wrote:
> Nope, just the fact that there always will configurations we do not
> support. And the best we can do is to sum all of those we do support.
> For example: Linux user may read the configuration we do support, install
> all of the needed environment and run the VM happily. It could better
> solution (or alternative) for user then asking a forum and waiting a fix.
A better solution would be if he sends us a patch which fixes his problem. It
is open source, isn't it? If it doesn't work for you, fix it yourself. The
more people care about some platform or configuration, the better it works.
Being more serious, is gcc version so important? I mean gcc is slowly
hardening rules of C/C++ language interpretation. That is the reason why we
had problems moving from 3.3 to 3.4 and then to 4.x. Personally I use 4.1.1
which is the latest stable for Gentoo and it compiles harmony ok. The
warnings which were fixed for 4.x don't cause problems on older versions.
Should be also specify compilation flags? Like we
support -mprefetch-loop-arrays but don't support -funroll-all-loops? It looks
silly to me. All software has bugs and we may encounter bugs in gcc just like
everyone else. Those who have problems with some particular version can
investigate and possibly find a solution or workaround. Those who don't want
to deal with it can use a binary build.
> On 10 Oct 2006 19:45:49 +0700, Egor Pasko <eg...@gmail.com> wrote:
> > On the 0x1FE day of Apache Harmony Mikhail Fursov wrote:
> > > On 10 Oct 2006 19:29:06 +0700, Egor Pasko <eg...@gmail.com> wrote:
> > > > why hide from problems? let's fix 'em all (jokingly)
> > >
> > > Is it possible with Linux? :)
> >
> > holy war? :)
--
Gregory Shimansky, 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mikhail Fursov <mi...@gmail.com>.
Nope, just the fact that there always will configurations we do not support.
And the best we can do is to sum all of those we do support.
For example: Linux user may read the configuration we do support, install
all of the needed environment and run the VM happily. It could better
solution (or alternative) for user then asking a forum and waiting a fix.
On 10 Oct 2006 19:45:49 +0700, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x1FE day of Apache Harmony Mikhail Fursov wrote:
> > On 10 Oct 2006 19:29:06 +0700, Egor Pasko <eg...@gmail.com> wrote:
> > >
> > > why hide from problems? let's fix 'em all (jokingly)
> > >
> >
> > Is it possible with Linux? :)
>
> holy war? :)
>
> --
> Egor Pasko, Intel Managed Runtime 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
>
>
--
Mikhail Fursov
Re: [general] define pre-commit testing configs to gain the stability
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1FE day of Apache Harmony Mikhail Fursov wrote:
> On 10 Oct 2006 19:29:06 +0700, Egor Pasko <eg...@gmail.com> wrote:
> >
> > why hide from problems? let's fix 'em all (jokingly)
> >
>
> Is it possible with Linux? :)
holy war? :)
--
Egor Pasko, Intel Managed Runtime 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10 Oct 2006 19:29:06 +0700, Egor Pasko <eg...@gmail.com> wrote:
>
> why hide from problems? let's fix 'em all (jokingly)
>
Is it possible with Linux? :)
--
Mikhail Fursov
Re: [general] define pre-commit testing configs to gain the stability
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1FE day of Apache Harmony Pavel Ozhdikhin wrote:
> On 10/10/06, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > On 10 October 2006 at 18:52, "Pavel Ozhdikhin" <pa...@gmail.com> wrote:
> > > Oh, again! Classlib is broken on Linux right now! :(
> > > And it was not me who did this to illustrate the problem. :)
> >
> > You are obviously using the wrong version of gcc! It compiles and all
> > tests pass for me. ;-)
>
> Ok, let's agree which one we will use. I'll switch to it and will be happy! :)
why hide from problems? let's fix 'em all (jokingly)
> >
> > -Mark.
> >
> > > On 10/10/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > > > I also think the diversity is generally good. Let's test Harmony on as
> > > > many platfroms as possible and find as many problems as we can. But I
> > > > also think that having at least one stable configuration is very
> > > > important for those who wants to work on the new features. Doing this
> > > > kind of work I'd prefer to have, say, 1 platfrom stable 99% of time
> > > > than 99 platforms stable 1% of time.
> > > >
> > > > I deeply appreciate the responsible committers like you who test the
> > > > patches thoroughly. But the overall process seems is not perfect since
> > > > the workspace breaks up again and again. Unfortunately tightening
> > > > pre-commit criteria seems to me the only way to prevent breakage.
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On 10/9/06, Mark Hindess <ma...@googlemail.com> wrote:
> > > > >
> > > > > On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <pa...@gmail.com>
> > > wrote:
> > > > > > On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > > > > > > Rana Dasgupta wrote:
> > > > > > > > We need to check both release and debug builds...the binaries and t
> > > iming
> > > > > > > > characteristics are too different. At this immediate stage of the
> > > > > > > > project, I
> > > > > > > > would suggest leaving out EM64T as part of mandatory testing( unles
> > > s it i
> > > > > > s
> > > > > > > > EM64T specific functionality, eg., codegen ). Too few contributors
> > > and
> > > > > > > > committers have access to it. We are not yet at a stage where we ca
> > > n make
> > > > > > > > this mandatory.
> > > > > > > >
> > > > > > > > If possible all submissions should be tested( by submitters ) on al
> > > l the
> > > > > > > > combinations identified . It is actually more urgent for submitters
> > > to do
> > > > > > > > this. We should stop patches by email. Also, at this point, it is a
> > > n hono
> > > > > > r
> > > > > > > > system, we can't attach 6 before and after test logs to each JIRA
> > > > > > > > submission. The committer could randomly check on one or more combi
> > > nation
> > > > > > ,
> > > > > > > > ...the more the better obviously.
> > > > > > > >
> > > > > > > > In some cases, submissions will be platform specific ( eg., very ne
> > > w code
> > > > > > > > like GC V5, platform specific bug fixes or a simple case of develop
> > > er not
> > > > > > > > having all the machines ). I would leave these to the committers'
> > > > > > > > discretion.
> > > > > > >
> > > > > > > Mandating that patches are pre-tested on a wide variety of machines i
> > > s
> > > > > > > not conducive to building a broad community of contributors since ver
> > > y
> > > > > > > few people have access to all the machines and configurations we are
> > > > > > > interested in. I'd much prefer that we work optimistically and have
> > > > > > > lots of people regularly building and testing the code to get the
> > > > > > > broadest possible coverage. We can backtrack if problems arise.
> > > > >
> > > > > Agreed. Broadest possible coverage is much more important.
> > > > >
> > > > > > Even is a committer does't have a wide variety of machines I think we
> > > > > > can still mandate that his/her commits are checked on the right
> > > > > > configuration.
> > > > >
> > > > > You'd also need to mandate linker versions and assembler versions too.
> > > > >
> > > > > > If the majority works on GCC 4.0.3 checking the patch on GCC 3.3.2
> > > > > > might not reveal the problems. Regular testing will, but the time
> > > > > > spend on backtracking is lost. The proposal is not only about variety
> > > > > > of configurations but is also about configurations themselves. Rana
> > > > > > proposed to exclude EM64T and add debug configs, so for now the list
> > > > > > is following:
> > > > > >
> > > > > > - Windows / IA32 / MSVS .NET 2003 / release
> > > > > > - Windows / IA32 / MSVS .NET 2003 / debug
> > > > > > - Linux / IA32 / GCC 4.0.3 / release
> > > > > > - Linux / IA32 / GCC 4.0.3 / debug
> > > > > > - Linux / EM64T / GCC 4.0.3 / release
> > > > > > - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> > > > > > but at least Geir has a machine)
> > > > >
> > > > > I'm a committer. I test most patches on my ia32 thinkpad, which is
> > > > > running Debian/testing (mostly). I've got the following compilers
> > > > > installed:
> > > > >
> > > > > gcc-2.95
> > > > > gcc-3.0
> > > > > gcc-3.2
> > > > > gcc-3.3
> > > > > gcc-3.4
> > > > > gcc-4.0
> > > > > gcc-4.1
> > > > >
> > > > > It turns out that my gcc-4.0 despite belonging to a package with a
> > > > > version number of "4.0.3-3" might not be gcc-4.0.3 because "gcc -v"
> > > > > says:
> > > > >
> > > > > gcc-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
> > > > >
> > > > > So I guess my 4.0.3 and, for example, Geir's on ubuntu are probably
> > > > > different.
> > > > >
> > > > > I don't plan to compile a new version of 4.0.3 from fresh sources (or
> > > > > install the ubuntu version or anything like that) because:
> > > > >
> > > > > 1) I don't think it matters that much
> > > > >
> > > > > 2) Next week we'd probably find a binutils problem and I'm definitely
> > > > > not changing that.
> > > > >
> > > > > 3) I actually think diversity is ok. I've not really seen a huge amount
> > > > > of problems with different gcc versions. And if there are problems with
> > > > > compiler incompatibilities then I want them to receive focus quickly -
> > > > > breaking is a good way to get peoples attention. What I'd really not
> > > > > want is for problems to go unnoticed because all the committers have
> > > > > spent time setting up their machines to be identical.
> > > > >
> > > > > > Assuming you are testing you commits on one of the machines above, do
> > > > > > you agree it make sense all committers to use the same configuration?
> > > > >
> > > > > No.
> > > > >
> > > > > > For example, if you use Linux/IA32 and another committer uses
> > > > > > Linux/IA32, do you agree that it makes sense to use the same compiler
> > > > > > versions for pre-commit testing?
> > > > >
> > > > > No.
> > > > >
> > > > > I agree that if all committers used exactly the same versions of
> > > > > compilers, linkers, etc. then we would most likely *see* fewer problems.
> > > > >
> > > > > However, I wouldn't sleep better because I'd know that the problems
> > > > > were still there waiting to bite us later. Personally I'd rather see
> > > > > problems as soon as possible.
> > > > >
> > > > > > Contributors are still free to check their patches whenever they want
> > > > > > or don't test them at all, but they should know what to expect from
> > > > > > the committers.
> > > > >
> > > > > Why? If a contributor submits a patch that they tested with gcc 4.0.3
> > > > > but that doesn't work for me with my gcc 4.0.[3/4] whatever it really
> > > > > is then I'm really not going to be upset about it. It just means we've
> > > > > learnt a valuable lesson that we'd not have learnt if I was running the
> > > > > identical 4.0.3.
> > > > >
> > > > > "Contributors don't have to test their patches at all"? I don't think
> > > > > committers should have to test them either then. ;-) <chanting>Equal
> > > > > rights for committers!</chanting>
> > > > >
> > > > >
> > > > > I tested the patch from
> > > > > https://issues.apache.org/jira/browse/HARMONY-1594 on all seven of the
> > > > > compilers on my laptop (it didn't actually work on all of them but it
> > > > > did make things better). I did this because:
> > > > >
> > > > > 1) there was a fairly high chance (compared to other patches) that this
> > > > > one was going to break compatibility with compilers since it was about
> > > > > compiler differences
> > > > >
> > > > > 2) Geir had asked that it be checked and I didn't want to break things
> > > > > for him because he's been doing so much work on drlvm recently
> > > > >
> > > > > This doesn't mean that I'm going to do that for every patch and I
> > > > > certainly wouldn't expect that kind of behaviour from all committers.
> > > > >
> > > > > I trust my fellow committers will do a reasonable amount of testing
> > > > > based on the nature of the patch.
> > > > >
> > > > > -Mark.
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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
>
>
--
Egor Pasko, Intel Managed Runtime 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 10/10/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 10 October 2006 at 18:52, "Pavel Ozhdikhin" <pa...@gmail.com> wrote:
> > Oh, again! Classlib is broken on Linux right now! :(
> > And it was not me who did this to illustrate the problem. :)
>
> You are obviously using the wrong version of gcc! It compiles and all
> tests pass for me. ;-)
Ok, let's agree which one we will use. I'll switch to it and will be happy! :)
>
> -Mark.
>
> > On 10/10/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > > I also think the diversity is generally good. Let's test Harmony on as
> > > many platfroms as possible and find as many problems as we can. But I
> > > also think that having at least one stable configuration is very
> > > important for those who wants to work on the new features. Doing this
> > > kind of work I'd prefer to have, say, 1 platfrom stable 99% of time
> > > than 99 platforms stable 1% of time.
> > >
> > > I deeply appreciate the responsible committers like you who test the
> > > patches thoroughly. But the overall process seems is not perfect since
> > > the workspace breaks up again and again. Unfortunately tightening
> > > pre-commit criteria seems to me the only way to prevent breakage.
> > >
> > > Thanks,
> > > Pavel
> > >
> > > On 10/9/06, Mark Hindess <ma...@googlemail.com> wrote:
> > > >
> > > > On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <pa...@gmail.com>
> > wrote:
> > > > > On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > > > > > Rana Dasgupta wrote:
> > > > > > > We need to check both release and debug builds...the binaries and t
> > iming
> > > > > > > characteristics are too different. At this immediate stage of the
> > > > > > > project, I
> > > > > > > would suggest leaving out EM64T as part of mandatory testing( unles
> > s it i
> > > > > s
> > > > > > > EM64T specific functionality, eg., codegen ). Too few contributors
> > and
> > > > > > > committers have access to it. We are not yet at a stage where we ca
> > n make
> > > > > > > this mandatory.
> > > > > > >
> > > > > > > If possible all submissions should be tested( by submitters ) on al
> > l the
> > > > > > > combinations identified . It is actually more urgent for submitters
> > to do
> > > > > > > this. We should stop patches by email. Also, at this point, it is a
> > n hono
> > > > > r
> > > > > > > system, we can't attach 6 before and after test logs to each JIRA
> > > > > > > submission. The committer could randomly check on one or more combi
> > nation
> > > > > ,
> > > > > > > ...the more the better obviously.
> > > > > > >
> > > > > > > In some cases, submissions will be platform specific ( eg., very ne
> > w code
> > > > > > > like GC V5, platform specific bug fixes or a simple case of develop
> > er not
> > > > > > > having all the machines ). I would leave these to the committers'
> > > > > > > discretion.
> > > > > >
> > > > > > Mandating that patches are pre-tested on a wide variety of machines i
> > s
> > > > > > not conducive to building a broad community of contributors since ver
> > y
> > > > > > few people have access to all the machines and configurations we are
> > > > > > interested in. I'd much prefer that we work optimistically and have
> > > > > > lots of people regularly building and testing the code to get the
> > > > > > broadest possible coverage. We can backtrack if problems arise.
> > > >
> > > > Agreed. Broadest possible coverage is much more important.
> > > >
> > > > > Even is a committer does't have a wide variety of machines I think we
> > > > > can still mandate that his/her commits are checked on the right
> > > > > configuration.
> > > >
> > > > You'd also need to mandate linker versions and assembler versions too.
> > > >
> > > > > If the majority works on GCC 4.0.3 checking the patch on GCC 3.3.2
> > > > > might not reveal the problems. Regular testing will, but the time
> > > > > spend on backtracking is lost. The proposal is not only about variety
> > > > > of configurations but is also about configurations themselves. Rana
> > > > > proposed to exclude EM64T and add debug configs, so for now the list
> > > > > is following:
> > > > >
> > > > > - Windows / IA32 / MSVS .NET 2003 / release
> > > > > - Windows / IA32 / MSVS .NET 2003 / debug
> > > > > - Linux / IA32 / GCC 4.0.3 / release
> > > > > - Linux / IA32 / GCC 4.0.3 / debug
> > > > > - Linux / EM64T / GCC 4.0.3 / release
> > > > > - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> > > > > but at least Geir has a machine)
> > > >
> > > > I'm a committer. I test most patches on my ia32 thinkpad, which is
> > > > running Debian/testing (mostly). I've got the following compilers
> > > > installed:
> > > >
> > > > gcc-2.95
> > > > gcc-3.0
> > > > gcc-3.2
> > > > gcc-3.3
> > > > gcc-3.4
> > > > gcc-4.0
> > > > gcc-4.1
> > > >
> > > > It turns out that my gcc-4.0 despite belonging to a package with a
> > > > version number of "4.0.3-3" might not be gcc-4.0.3 because "gcc -v"
> > > > says:
> > > >
> > > > gcc-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
> > > >
> > > > So I guess my 4.0.3 and, for example, Geir's on ubuntu are probably
> > > > different.
> > > >
> > > > I don't plan to compile a new version of 4.0.3 from fresh sources (or
> > > > install the ubuntu version or anything like that) because:
> > > >
> > > > 1) I don't think it matters that much
> > > >
> > > > 2) Next week we'd probably find a binutils problem and I'm definitely
> > > > not changing that.
> > > >
> > > > 3) I actually think diversity is ok. I've not really seen a huge amount
> > > > of problems with different gcc versions. And if there are problems with
> > > > compiler incompatibilities then I want them to receive focus quickly -
> > > > breaking is a good way to get peoples attention. What I'd really not
> > > > want is for problems to go unnoticed because all the committers have
> > > > spent time setting up their machines to be identical.
> > > >
> > > > > Assuming you are testing you commits on one of the machines above, do
> > > > > you agree it make sense all committers to use the same configuration?
> > > >
> > > > No.
> > > >
> > > > > For example, if you use Linux/IA32 and another committer uses
> > > > > Linux/IA32, do you agree that it makes sense to use the same compiler
> > > > > versions for pre-commit testing?
> > > >
> > > > No.
> > > >
> > > > I agree that if all committers used exactly the same versions of
> > > > compilers, linkers, etc. then we would most likely *see* fewer problems.
> > > >
> > > > However, I wouldn't sleep better because I'd know that the problems
> > > > were still there waiting to bite us later. Personally I'd rather see
> > > > problems as soon as possible.
> > > >
> > > > > Contributors are still free to check their patches whenever they want
> > > > > or don't test them at all, but they should know what to expect from
> > > > > the committers.
> > > >
> > > > Why? If a contributor submits a patch that they tested with gcc 4.0.3
> > > > but that doesn't work for me with my gcc 4.0.[3/4] whatever it really
> > > > is then I'm really not going to be upset about it. It just means we've
> > > > learnt a valuable lesson that we'd not have learnt if I was running the
> > > > identical 4.0.3.
> > > >
> > > > "Contributors don't have to test their patches at all"? I don't think
> > > > committers should have to test them either then. ;-) <chanting>Equal
> > > > rights for committers!</chanting>
> > > >
> > > >
> > > > I tested the patch from
> > > > https://issues.apache.org/jira/browse/HARMONY-1594 on all seven of the
> > > > compilers on my laptop (it didn't actually work on all of them but it
> > > > did make things better). I did this because:
> > > >
> > > > 1) there was a fairly high chance (compared to other patches) that this
> > > > one was going to break compatibility with compilers since it was about
> > > > compiler differences
> > > >
> > > > 2) Geir had asked that it be checked and I didn't want to break things
> > > > for him because he's been doing so much work on drlvm recently
> > > >
> > > > This doesn't mean that I'm going to do that for every patch and I
> > > > certainly wouldn't expect that kind of behaviour from all committers.
> > > >
> > > > I trust my fellow committers will do a reasonable amount of testing
> > > > based on the nature of the patch.
> > > >
> > > > -Mark.
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mark Hindess <ma...@googlemail.com>.
On 10 October 2006 at 18:52, "Pavel Ozhdikhin" <pa...@gmail.com> wrote:
> Oh, again! Classlib is broken on Linux right now! :(
> And it was not me who did this to illustrate the problem. :)
You are obviously using the wrong version of gcc! It compiles and all
tests pass for me. ;-)
-Mark.
> On 10/10/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > I also think the diversity is generally good. Let's test Harmony on as
> > many platfroms as possible and find as many problems as we can. But I
> > also think that having at least one stable configuration is very
> > important for those who wants to work on the new features. Doing this
> > kind of work I'd prefer to have, say, 1 platfrom stable 99% of time
> > than 99 platforms stable 1% of time.
> >
> > I deeply appreciate the responsible committers like you who test the
> > patches thoroughly. But the overall process seems is not perfect since
> > the workspace breaks up again and again. Unfortunately tightening
> > pre-commit criteria seems to me the only way to prevent breakage.
> >
> > Thanks,
> > Pavel
> >
> > On 10/9/06, Mark Hindess <ma...@googlemail.com> wrote:
> > >
> > > On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <pa...@gmail.com>
> wrote:
> > > > On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > > > > Rana Dasgupta wrote:
> > > > > > We need to check both release and debug builds...the binaries and t
> iming
> > > > > > characteristics are too different. At this immediate stage of the
> > > > > > project, I
> > > > > > would suggest leaving out EM64T as part of mandatory testing( unles
> s it i
> > > > s
> > > > > > EM64T specific functionality, eg., codegen ). Too few contributors
> and
> > > > > > committers have access to it. We are not yet at a stage where we ca
> n make
> > > > > > this mandatory.
> > > > > >
> > > > > > If possible all submissions should be tested( by submitters ) on al
> l the
> > > > > > combinations identified . It is actually more urgent for submitters
> to do
> > > > > > this. We should stop patches by email. Also, at this point, it is a
> n hono
> > > > r
> > > > > > system, we can't attach 6 before and after test logs to each JIRA
> > > > > > submission. The committer could randomly check on one or more combi
> nation
> > > > ,
> > > > > > ...the more the better obviously.
> > > > > >
> > > > > > In some cases, submissions will be platform specific ( eg., very ne
> w code
> > > > > > like GC V5, platform specific bug fixes or a simple case of develop
> er not
> > > > > > having all the machines ). I would leave these to the committers'
> > > > > > discretion.
> > > > >
> > > > > Mandating that patches are pre-tested on a wide variety of machines i
> s
> > > > > not conducive to building a broad community of contributors since ver
> y
> > > > > few people have access to all the machines and configurations we are
> > > > > interested in. I'd much prefer that we work optimistically and have
> > > > > lots of people regularly building and testing the code to get the
> > > > > broadest possible coverage. We can backtrack if problems arise.
> > >
> > > Agreed. Broadest possible coverage is much more important.
> > >
> > > > Even is a committer does't have a wide variety of machines I think we
> > > > can still mandate that his/her commits are checked on the right
> > > > configuration.
> > >
> > > You'd also need to mandate linker versions and assembler versions too.
> > >
> > > > If the majority works on GCC 4.0.3 checking the patch on GCC 3.3.2
> > > > might not reveal the problems. Regular testing will, but the time
> > > > spend on backtracking is lost. The proposal is not only about variety
> > > > of configurations but is also about configurations themselves. Rana
> > > > proposed to exclude EM64T and add debug configs, so for now the list
> > > > is following:
> > > >
> > > > - Windows / IA32 / MSVS .NET 2003 / release
> > > > - Windows / IA32 / MSVS .NET 2003 / debug
> > > > - Linux / IA32 / GCC 4.0.3 / release
> > > > - Linux / IA32 / GCC 4.0.3 / debug
> > > > - Linux / EM64T / GCC 4.0.3 / release
> > > > - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> > > > but at least Geir has a machine)
> > >
> > > I'm a committer. I test most patches on my ia32 thinkpad, which is
> > > running Debian/testing (mostly). I've got the following compilers
> > > installed:
> > >
> > > gcc-2.95
> > > gcc-3.0
> > > gcc-3.2
> > > gcc-3.3
> > > gcc-3.4
> > > gcc-4.0
> > > gcc-4.1
> > >
> > > It turns out that my gcc-4.0 despite belonging to a package with a
> > > version number of "4.0.3-3" might not be gcc-4.0.3 because "gcc -v"
> > > says:
> > >
> > > gcc-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
> > >
> > > So I guess my 4.0.3 and, for example, Geir's on ubuntu are probably
> > > different.
> > >
> > > I don't plan to compile a new version of 4.0.3 from fresh sources (or
> > > install the ubuntu version or anything like that) because:
> > >
> > > 1) I don't think it matters that much
> > >
> > > 2) Next week we'd probably find a binutils problem and I'm definitely
> > > not changing that.
> > >
> > > 3) I actually think diversity is ok. I've not really seen a huge amount
> > > of problems with different gcc versions. And if there are problems with
> > > compiler incompatibilities then I want them to receive focus quickly -
> > > breaking is a good way to get peoples attention. What I'd really not
> > > want is for problems to go unnoticed because all the committers have
> > > spent time setting up their machines to be identical.
> > >
> > > > Assuming you are testing you commits on one of the machines above, do
> > > > you agree it make sense all committers to use the same configuration?
> > >
> > > No.
> > >
> > > > For example, if you use Linux/IA32 and another committer uses
> > > > Linux/IA32, do you agree that it makes sense to use the same compiler
> > > > versions for pre-commit testing?
> > >
> > > No.
> > >
> > > I agree that if all committers used exactly the same versions of
> > > compilers, linkers, etc. then we would most likely *see* fewer problems.
> > >
> > > However, I wouldn't sleep better because I'd know that the problems
> > > were still there waiting to bite us later. Personally I'd rather see
> > > problems as soon as possible.
> > >
> > > > Contributors are still free to check their patches whenever they want
> > > > or don't test them at all, but they should know what to expect from
> > > > the committers.
> > >
> > > Why? If a contributor submits a patch that they tested with gcc 4.0.3
> > > but that doesn't work for me with my gcc 4.0.[3/4] whatever it really
> > > is then I'm really not going to be upset about it. It just means we've
> > > learnt a valuable lesson that we'd not have learnt if I was running the
> > > identical 4.0.3.
> > >
> > > "Contributors don't have to test their patches at all"? I don't think
> > > committers should have to test them either then. ;-) <chanting>Equal
> > > rights for committers!</chanting>
> > >
> > >
> > > I tested the patch from
> > > https://issues.apache.org/jira/browse/HARMONY-1594 on all seven of the
> > > compilers on my laptop (it didn't actually work on all of them but it
> > > did make things better). I did this because:
> > >
> > > 1) there was a fairly high chance (compared to other patches) that this
> > > one was going to break compatibility with compilers since it was about
> > > compiler differences
> > >
> > > 2) Geir had asked that it be checked and I didn't want to break things
> > > for him because he's been doing so much work on drlvm recently
> > >
> > > This doesn't mean that I'm going to do that for every patch and I
> > > certainly wouldn't expect that kind of behaviour from all committers.
> > >
> > > I trust my fellow committers will do a reasonable amount of testing
> > > based on the nature of the patch.
> > >
> > > -Mark.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
Oh, again! Classlib is broken on Linux right now! :(
And it was not me who did this to illustrate the problem. :)
On 10/10/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> I also think the diversity is generally good. Let's test Harmony on as
> many platfroms as possible and find as many problems as we can. But I
> also think that having at least one stable configuration is very
> important for those who wants to work on the new features. Doing this
> kind of work I'd prefer to have, say, 1 platfrom stable 99% of time
> than 99 platforms stable 1% of time.
>
> I deeply appreciate the responsible committers like you who test the
> patches thoroughly. But the overall process seems is not perfect since
> the workspace breaks up again and again. Unfortunately tightening
> pre-commit criteria seems to me the only way to prevent breakage.
>
> Thanks,
> Pavel
>
> On 10/9/06, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <pa...@gmail.com> wrote:
> > > On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > > > Rana Dasgupta wrote:
> > > > > We need to check both release and debug builds...the binaries and timing
> > > > > characteristics are too different. At this immediate stage of the
> > > > > project, I
> > > > > would suggest leaving out EM64T as part of mandatory testing( unless it i
> > > s
> > > > > EM64T specific functionality, eg., codegen ). Too few contributors and
> > > > > committers have access to it. We are not yet at a stage where we can make
> > > > > this mandatory.
> > > > >
> > > > > If possible all submissions should be tested( by submitters ) on all the
> > > > > combinations identified . It is actually more urgent for submitters to do
> > > > > this. We should stop patches by email. Also, at this point, it is an hono
> > > r
> > > > > system, we can't attach 6 before and after test logs to each JIRA
> > > > > submission. The committer could randomly check on one or more combination
> > > ,
> > > > > ...the more the better obviously.
> > > > >
> > > > > In some cases, submissions will be platform specific ( eg., very new code
> > > > > like GC V5, platform specific bug fixes or a simple case of developer not
> > > > > having all the machines ). I would leave these to the committers'
> > > > > discretion.
> > > >
> > > > Mandating that patches are pre-tested on a wide variety of machines is
> > > > not conducive to building a broad community of contributors since very
> > > > few people have access to all the machines and configurations we are
> > > > interested in. I'd much prefer that we work optimistically and have
> > > > lots of people regularly building and testing the code to get the
> > > > broadest possible coverage. We can backtrack if problems arise.
> >
> > Agreed. Broadest possible coverage is much more important.
> >
> > > Even is a committer does't have a wide variety of machines I think we
> > > can still mandate that his/her commits are checked on the right
> > > configuration.
> >
> > You'd also need to mandate linker versions and assembler versions too.
> >
> > > If the majority works on GCC 4.0.3 checking the patch on GCC 3.3.2
> > > might not reveal the problems. Regular testing will, but the time
> > > spend on backtracking is lost. The proposal is not only about variety
> > > of configurations but is also about configurations themselves. Rana
> > > proposed to exclude EM64T and add debug configs, so for now the list
> > > is following:
> > >
> > > - Windows / IA32 / MSVS .NET 2003 / release
> > > - Windows / IA32 / MSVS .NET 2003 / debug
> > > - Linux / IA32 / GCC 4.0.3 / release
> > > - Linux / IA32 / GCC 4.0.3 / debug
> > > - Linux / EM64T / GCC 4.0.3 / release
> > > - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> > > but at least Geir has a machine)
> >
> > I'm a committer. I test most patches on my ia32 thinkpad, which is
> > running Debian/testing (mostly). I've got the following compilers
> > installed:
> >
> > gcc-2.95
> > gcc-3.0
> > gcc-3.2
> > gcc-3.3
> > gcc-3.4
> > gcc-4.0
> > gcc-4.1
> >
> > It turns out that my gcc-4.0 despite belonging to a package with a
> > version number of "4.0.3-3" might not be gcc-4.0.3 because "gcc -v"
> > says:
> >
> > gcc-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
> >
> > So I guess my 4.0.3 and, for example, Geir's on ubuntu are probably
> > different.
> >
> > I don't plan to compile a new version of 4.0.3 from fresh sources (or
> > install the ubuntu version or anything like that) because:
> >
> > 1) I don't think it matters that much
> >
> > 2) Next week we'd probably find a binutils problem and I'm definitely
> > not changing that.
> >
> > 3) I actually think diversity is ok. I've not really seen a huge amount
> > of problems with different gcc versions. And if there are problems with
> > compiler incompatibilities then I want them to receive focus quickly -
> > breaking is a good way to get peoples attention. What I'd really not
> > want is for problems to go unnoticed because all the committers have
> > spent time setting up their machines to be identical.
> >
> > > Assuming you are testing you commits on one of the machines above, do
> > > you agree it make sense all committers to use the same configuration?
> >
> > No.
> >
> > > For example, if you use Linux/IA32 and another committer uses
> > > Linux/IA32, do you agree that it makes sense to use the same compiler
> > > versions for pre-commit testing?
> >
> > No.
> >
> > I agree that if all committers used exactly the same versions of
> > compilers, linkers, etc. then we would most likely *see* fewer problems.
> >
> > However, I wouldn't sleep better because I'd know that the problems
> > were still there waiting to bite us later. Personally I'd rather see
> > problems as soon as possible.
> >
> > > Contributors are still free to check their patches whenever they want
> > > or don't test them at all, but they should know what to expect from
> > > the committers.
> >
> > Why? If a contributor submits a patch that they tested with gcc 4.0.3
> > but that doesn't work for me with my gcc 4.0.[3/4] whatever it really
> > is then I'm really not going to be upset about it. It just means we've
> > learnt a valuable lesson that we'd not have learnt if I was running the
> > identical 4.0.3.
> >
> > "Contributors don't have to test their patches at all"? I don't think
> > committers should have to test them either then. ;-) <chanting>Equal
> > rights for committers!</chanting>
> >
> >
> > I tested the patch from
> > https://issues.apache.org/jira/browse/HARMONY-1594 on all seven of the
> > compilers on my laptop (it didn't actually work on all of them but it
> > did make things better). I did this because:
> >
> > 1) there was a fairly high chance (compared to other patches) that this
> > one was going to break compatibility with compilers since it was about
> > compiler differences
> >
> > 2) Geir had asked that it be checked and I didn't want to break things
> > for him because he's been doing so much work on drlvm recently
> >
> > This doesn't mean that I'm going to do that for every patch and I
> > certainly wouldn't expect that kind of behaviour from all committers.
> >
> > I trust my fellow committers will do a reasonable amount of testing
> > based on the nature of the patch.
> >
> > -Mark.
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
I also think the diversity is generally good. Let's test Harmony on as
many platfroms as possible and find as many problems as we can. But I
also think that having at least one stable configuration is very
important for those who wants to work on the new features. Doing this
kind of work I'd prefer to have, say, 1 platfrom stable 99% of time
than 99 platforms stable 1% of time.
I deeply appreciate the responsible committers like you who test the
patches thoroughly. But the overall process seems is not perfect since
the workspace breaks up again and again. Unfortunately tightening
pre-commit criteria seems to me the only way to prevent breakage.
Thanks,
Pavel
On 10/9/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <pa...@gmail.com> wrote:
> > On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > > Rana Dasgupta wrote:
> > > > We need to check both release and debug builds...the binaries and timing
> > > > characteristics are too different. At this immediate stage of the
> > > > project, I
> > > > would suggest leaving out EM64T as part of mandatory testing( unless it i
> > s
> > > > EM64T specific functionality, eg., codegen ). Too few contributors and
> > > > committers have access to it. We are not yet at a stage where we can make
> > > > this mandatory.
> > > >
> > > > If possible all submissions should be tested( by submitters ) on all the
> > > > combinations identified . It is actually more urgent for submitters to do
> > > > this. We should stop patches by email. Also, at this point, it is an hono
> > r
> > > > system, we can't attach 6 before and after test logs to each JIRA
> > > > submission. The committer could randomly check on one or more combination
> > ,
> > > > ...the more the better obviously.
> > > >
> > > > In some cases, submissions will be platform specific ( eg., very new code
> > > > like GC V5, platform specific bug fixes or a simple case of developer not
> > > > having all the machines ). I would leave these to the committers'
> > > > discretion.
> > >
> > > Mandating that patches are pre-tested on a wide variety of machines is
> > > not conducive to building a broad community of contributors since very
> > > few people have access to all the machines and configurations we are
> > > interested in. I'd much prefer that we work optimistically and have
> > > lots of people regularly building and testing the code to get the
> > > broadest possible coverage. We can backtrack if problems arise.
>
> Agreed. Broadest possible coverage is much more important.
>
> > Even is a committer does't have a wide variety of machines I think we
> > can still mandate that his/her commits are checked on the right
> > configuration.
>
> You'd also need to mandate linker versions and assembler versions too.
>
> > If the majority works on GCC 4.0.3 checking the patch on GCC 3.3.2
> > might not reveal the problems. Regular testing will, but the time
> > spend on backtracking is lost. The proposal is not only about variety
> > of configurations but is also about configurations themselves. Rana
> > proposed to exclude EM64T and add debug configs, so for now the list
> > is following:
> >
> > - Windows / IA32 / MSVS .NET 2003 / release
> > - Windows / IA32 / MSVS .NET 2003 / debug
> > - Linux / IA32 / GCC 4.0.3 / release
> > - Linux / IA32 / GCC 4.0.3 / debug
> > - Linux / EM64T / GCC 4.0.3 / release
> > - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> > but at least Geir has a machine)
>
> I'm a committer. I test most patches on my ia32 thinkpad, which is
> running Debian/testing (mostly). I've got the following compilers
> installed:
>
> gcc-2.95
> gcc-3.0
> gcc-3.2
> gcc-3.3
> gcc-3.4
> gcc-4.0
> gcc-4.1
>
> It turns out that my gcc-4.0 despite belonging to a package with a
> version number of "4.0.3-3" might not be gcc-4.0.3 because "gcc -v"
> says:
>
> gcc-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
>
> So I guess my 4.0.3 and, for example, Geir's on ubuntu are probably
> different.
>
> I don't plan to compile a new version of 4.0.3 from fresh sources (or
> install the ubuntu version or anything like that) because:
>
> 1) I don't think it matters that much
>
> 2) Next week we'd probably find a binutils problem and I'm definitely
> not changing that.
>
> 3) I actually think diversity is ok. I've not really seen a huge amount
> of problems with different gcc versions. And if there are problems with
> compiler incompatibilities then I want them to receive focus quickly -
> breaking is a good way to get peoples attention. What I'd really not
> want is for problems to go unnoticed because all the committers have
> spent time setting up their machines to be identical.
>
> > Assuming you are testing you commits on one of the machines above, do
> > you agree it make sense all committers to use the same configuration?
>
> No.
>
> > For example, if you use Linux/IA32 and another committer uses
> > Linux/IA32, do you agree that it makes sense to use the same compiler
> > versions for pre-commit testing?
>
> No.
>
> I agree that if all committers used exactly the same versions of
> compilers, linkers, etc. then we would most likely *see* fewer problems.
>
> However, I wouldn't sleep better because I'd know that the problems
> were still there waiting to bite us later. Personally I'd rather see
> problems as soon as possible.
>
> > Contributors are still free to check their patches whenever they want
> > or don't test them at all, but they should know what to expect from
> > the committers.
>
> Why? If a contributor submits a patch that they tested with gcc 4.0.3
> but that doesn't work for me with my gcc 4.0.[3/4] whatever it really
> is then I'm really not going to be upset about it. It just means we've
> learnt a valuable lesson that we'd not have learnt if I was running the
> identical 4.0.3.
>
> "Contributors don't have to test their patches at all"? I don't think
> committers should have to test them either then. ;-) <chanting>Equal
> rights for committers!</chanting>
>
>
> I tested the patch from
> https://issues.apache.org/jira/browse/HARMONY-1594 on all seven of the
> compilers on my laptop (it didn't actually work on all of them but it
> did make things better). I did this because:
>
> 1) there was a fairly high chance (compared to other patches) that this
> one was going to break compatibility with compilers since it was about
> compiler differences
>
> 2) Geir had asked that it be checked and I didn't want to break things
> for him because he's been doing so much work on drlvm recently
>
> This doesn't mean that I'm going to do that for every patch and I
> certainly wouldn't expect that kind of behaviour from all committers.
>
> I trust my fellow committers will do a reasonable amount of testing
> based on the nature of the patch.
>
> -Mark.
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Oct 9, 2006, at 8:52 AM, Mark Hindess wrote:
>
> On 9 October 2006 at 16:12, "Pavel Ozhdikhin"
> <pa...@gmail.com> wrote:
>> On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
>>> Rana Dasgupta wrote:
>>>> We need to check both release and debug builds...the binaries
>>>> and timing
>>>> characteristics are too different. At this immediate stage of the
>>>> project, I
>>>> would suggest leaving out EM64T as part of mandatory testing
>>>> ( unless it i
>> s
>>>> EM64T specific functionality, eg., codegen ). Too few
>>>> contributors and
>>>> committers have access to it. We are not yet at a stage where we
>>>> can make
>>>> this mandatory.
>>>>
>>>> If possible all submissions should be tested( by submitters ) on
>>>> all the
>>>> combinations identified . It is actually more urgent for
>>>> submitters to do
>>>> this. We should stop patches by email. Also, at this point, it
>>>> is an hono
>> r
>>>> system, we can't attach 6 before and after test logs to each JIRA
>>>> submission. The committer could randomly check on one or more
>>>> combination
>> ,
>>>> ...the more the better obviously.
>>>>
>>>> In some cases, submissions will be platform specific ( eg., very
>>>> new code
>>>> like GC V5, platform specific bug fixes or a simple case of
>>>> developer not
>>>> having all the machines ). I would leave these to the committers'
>>>> discretion.
>>>
>>> Mandating that patches are pre-tested on a wide variety of
>>> machines is
>>> not conducive to building a broad community of contributors since
>>> very
>>> few people have access to all the machines and configurations we are
>>> interested in. I'd much prefer that we work optimistically and have
>>> lots of people regularly building and testing the code to get the
>>> broadest possible coverage. We can backtrack if problems arise.
>
> Agreed. Broadest possible coverage is much more important.
>
>> Even is a committer does't have a wide variety of machines I think we
>> can still mandate that his/her commits are checked on the right
>> configuration.
>
> You'd also need to mandate linker versions and assembler versions too.
Which I think we should do. I can see no good reason for not doing
this other than versions people port harmony too not having a given
version of the toolset available, but that's a problem I'd love to
have :)
[snip]
> I'm a committer. I test most patches on my ia32 thinkpad, which is
> running Debian/testing (mostly). I've got the following compilers
> installed:
>
> gcc-2.95
> gcc-3.0
> gcc-3.2
> gcc-3.3
> gcc-3.4
> gcc-4.0
> gcc-4.1
>
> It turns out that my gcc-4.0 despite belonging to a package with a
> version number of "4.0.3-3" might not be gcc-4.0.3 because "gcc -v"
> says:
>
> gcc-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
>
> So I guess my 4.0.3 and, for example, Geir's on ubuntu are probably
> different.
>
> I don't plan to compile a new version of 4.0.3 from fresh sources (or
> install the ubuntu version or anything like that) because:
>
> 1) I don't think it matters that much
>
> 2) Next week we'd probably find a binutils problem and I'm definitely
> not changing that.
>
> 3) I actually think diversity is ok. I've not really seen a huge
> amount
> of problems with different gcc versions. And if there are problems
> with
> compiler incompatibilities then I want them to receive focus quickly -
> breaking is a good way to get peoples attention. What I'd really not
> want is for problems to go unnoticed because all the committers have
> spent time setting up their machines to be identical.
Agreed, but they should be close, I believe.
geir
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mark Hindess <ma...@googlemail.com>.
On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <pa...@gmail.com> wrote:
> On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > Rana Dasgupta wrote:
> > > We need to check both release and debug builds...the binaries and timing
> > > characteristics are too different. At this immediate stage of the
> > > project, I
> > > would suggest leaving out EM64T as part of mandatory testing( unless it i
> s
> > > EM64T specific functionality, eg., codegen ). Too few contributors and
> > > committers have access to it. We are not yet at a stage where we can make
> > > this mandatory.
> > >
> > > If possible all submissions should be tested( by submitters ) on all the
> > > combinations identified . It is actually more urgent for submitters to do
> > > this. We should stop patches by email. Also, at this point, it is an hono
> r
> > > system, we can't attach 6 before and after test logs to each JIRA
> > > submission. The committer could randomly check on one or more combination
> ,
> > > ...the more the better obviously.
> > >
> > > In some cases, submissions will be platform specific ( eg., very new code
> > > like GC V5, platform specific bug fixes or a simple case of developer not
> > > having all the machines ). I would leave these to the committers'
> > > discretion.
> >
> > Mandating that patches are pre-tested on a wide variety of machines is
> > not conducive to building a broad community of contributors since very
> > few people have access to all the machines and configurations we are
> > interested in. I'd much prefer that we work optimistically and have
> > lots of people regularly building and testing the code to get the
> > broadest possible coverage. We can backtrack if problems arise.
Agreed. Broadest possible coverage is much more important.
> Even is a committer does't have a wide variety of machines I think we
> can still mandate that his/her commits are checked on the right
> configuration.
You'd also need to mandate linker versions and assembler versions too.
> If the majority works on GCC 4.0.3 checking the patch on GCC 3.3.2
> might not reveal the problems. Regular testing will, but the time
> spend on backtracking is lost. The proposal is not only about variety
> of configurations but is also about configurations themselves. Rana
> proposed to exclude EM64T and add debug configs, so for now the list
> is following:
>
> - Windows / IA32 / MSVS .NET 2003 / release
> - Windows / IA32 / MSVS .NET 2003 / debug
> - Linux / IA32 / GCC 4.0.3 / release
> - Linux / IA32 / GCC 4.0.3 / debug
> - Linux / EM64T / GCC 4.0.3 / release
> - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> but at least Geir has a machine)
I'm a committer. I test most patches on my ia32 thinkpad, which is
running Debian/testing (mostly). I've got the following compilers
installed:
gcc-2.95
gcc-3.0
gcc-3.2
gcc-3.3
gcc-3.4
gcc-4.0
gcc-4.1
It turns out that my gcc-4.0 despite belonging to a package with a
version number of "4.0.3-3" might not be gcc-4.0.3 because "gcc -v"
says:
gcc-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
So I guess my 4.0.3 and, for example, Geir's on ubuntu are probably
different.
I don't plan to compile a new version of 4.0.3 from fresh sources (or
install the ubuntu version or anything like that) because:
1) I don't think it matters that much
2) Next week we'd probably find a binutils problem and I'm definitely
not changing that.
3) I actually think diversity is ok. I've not really seen a huge amount
of problems with different gcc versions. And if there are problems with
compiler incompatibilities then I want them to receive focus quickly -
breaking is a good way to get peoples attention. What I'd really not
want is for problems to go unnoticed because all the committers have
spent time setting up their machines to be identical.
> Assuming you are testing you commits on one of the machines above, do
> you agree it make sense all committers to use the same configuration?
No.
> For example, if you use Linux/IA32 and another committer uses
> Linux/IA32, do you agree that it makes sense to use the same compiler
> versions for pre-commit testing?
No.
I agree that if all committers used exactly the same versions of
compilers, linkers, etc. then we would most likely *see* fewer problems.
However, I wouldn't sleep better because I'd know that the problems
were still there waiting to bite us later. Personally I'd rather see
problems as soon as possible.
> Contributors are still free to check their patches whenever they want
> or don't test them at all, but they should know what to expect from
> the committers.
Why? If a contributor submits a patch that they tested with gcc 4.0.3
but that doesn't work for me with my gcc 4.0.[3/4] whatever it really
is then I'm really not going to be upset about it. It just means we've
learnt a valuable lesson that we'd not have learnt if I was running the
identical 4.0.3.
"Contributors don't have to test their patches at all"? I don't think
committers should have to test them either then. ;-) <chanting>Equal
rights for committers!</chanting>
I tested the patch from
https://issues.apache.org/jira/browse/HARMONY-1594 on all seven of the
compilers on my laptop (it didn't actually work on all of them but it
did make things better). I did this because:
1) there was a fairly high chance (compared to other patches) that this
one was going to break compatibility with compilers since it was about
compiler differences
2) Geir had asked that it be checked and I didn't want to break things
for him because he's been doing so much work on drlvm recently
This doesn't mean that I'm going to do that for every patch and I
certainly wouldn't expect that kind of behaviour from all committers.
I trust my fellow committers will do a reasonable amount of testing
based on the nature of the patch.
-Mark.
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Ivan Volosyuk wrote:
> What an interesting discussion! I have just read this out. :)
>
> IMHO, all of the discussion is focused on the scalability of
> bazar-like development as it exists here in harmony incubator:
>
> If something wrong is commited, then everyone has broken build or
> something doesn't work. - This is bad. System is badly scalable. What
> can we do here?
Over time, evolve to a system where a build distributor checks each
commit before it's commited.
For now, we get good CI running all over the community so we know ASAP.
>
> If build is broken, then the cause might be found by someone and
> posted on harmony-dev. - This is good. And it has good scalability :)
>
> --
> Ivan
>
> On 10/14/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>>
>> Tim Ellison wrote:
>> > Geir Magnusson Jr. wrote:
>> >> If it turns out to be a big deal, we can simply add a pre-commit
>> target
>> >> to the build that checks for things like that. It could also check
>> for
>> >> things like tabs. If possible, it could be a pre-commit hook for svn,
>> >> but if not, in the build would be useful for those creating patches...
>> >
>> > Jeepers! Just hit return at the end of the file. If you screw-up the
>> > build system will slap you, we don't need scripts to fix this for us
>> > during commit/build.
>>
>> Hence... "if it turns out to be a big deal..."
>>
>> geir
>
> ---------------------------------------------------------------------
> 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
Bazaar is a funny concept. :) I think it'll work assuming we have a
bazaar police - something constantly checking integrity of our code on
some target platforms. These may be the community members reporting
failures or a tool constantly testing some target platforms. But this
tool is another topic for discussion.
Thanks,
Pavel
On 10/16/06, Tim Ellison <t....@gmail.com> wrote:
> Ivan Volosyuk wrote:
> > What an interesting discussion! I have just read this out. :)
> >
> > IMHO, all of the discussion is focused on the scalability of
> > bazar-like development as it exists here in harmony incubator:
> >
> > If something wrong is commited, then everyone has broken build or
> > something doesn't work. - This is bad. System is badly scalable. What
> > can we do here?
> >
> > If build is broken, then the cause might be found by someone and
> > posted on harmony-dev. - This is good. And it has good scalability :)
>
> Exactly -- we don't expect committers to be infallible or have every
> type of machine and OS version that we intend to 'support' (i.e. keep
> running), so we cannot have a model that requires such extensive
> pre-commit testing. Of course, we therefore need full community
> approval to declare some revision of code stable, but our bazaar-like
> diversity is truly an asset.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
>
> ---------------------------------------------------------------------
> 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Tim Ellison <t....@gmail.com>.
Ivan Volosyuk wrote:
> What an interesting discussion! I have just read this out. :)
>
> IMHO, all of the discussion is focused on the scalability of
> bazar-like development as it exists here in harmony incubator:
>
> If something wrong is commited, then everyone has broken build or
> something doesn't work. - This is bad. System is badly scalable. What
> can we do here?
>
> If build is broken, then the cause might be found by someone and
> posted on harmony-dev. - This is good. And it has good scalability :)
Exactly -- we don't expect committers to be infallible or have every
type of machine and OS version that we intend to 'support' (i.e. keep
running), so we cannot have a model that requires such extensive
pre-commit testing. Of course, we therefore need full community
approval to declare some revision of code stable, but our bazaar-like
diversity is truly an asset.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Ivan Volosyuk <iv...@gmail.com>.
What an interesting discussion! I have just read this out. :)
IMHO, all of the discussion is focused on the scalability of
bazar-like development as it exists here in harmony incubator:
If something wrong is commited, then everyone has broken build or
something doesn't work. - This is bad. System is badly scalable. What
can we do here?
If build is broken, then the cause might be found by someone and
posted on harmony-dev. - This is good. And it has good scalability :)
--
Ivan
On 10/14/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Tim Ellison wrote:
> > Geir Magnusson Jr. wrote:
> >> If it turns out to be a big deal, we can simply add a pre-commit target
> >> to the build that checks for things like that. It could also check for
> >> things like tabs. If possible, it could be a pre-commit hook for svn,
> >> but if not, in the build would be useful for those creating patches...
> >
> > Jeepers! Just hit return at the end of the file. If you screw-up the
> > build system will slap you, we don't need scripts to fix this for us
> > during commit/build.
>
> Hence... "if it turns out to be a big deal..."
>
> geir
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> If it turns out to be a big deal, we can simply add a pre-commit target
>> to the build that checks for things like that. It could also check for
>> things like tabs. If possible, it could be a pre-commit hook for svn,
>> but if not, in the build would be useful for those creating patches...
>
> Jeepers! Just hit return at the end of the file. If you screw-up the
> build system will slap you, we don't need scripts to fix this for us
> during commit/build.
Hence... "if it turns out to be a big deal..."
geir
>
> Regards,
> Tim
>
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mike Ringrose <mi...@gmail.com>.
I couldn't have said it better. :)
On 10/14/06, Tim Ellison <t....@gmail.com> wrote:
>
> Geir Magnusson Jr. wrote:
> > If it turns out to be a big deal, we can simply add a pre-commit target
> > to the build that checks for things like that. It could also check for
> > things like tabs. If possible, it could be a pre-commit hook for svn,
> > but if not, in the build would be useful for those creating patches...
>
> Jeepers! Just hit return at the end of the file. If you screw-up the
> build system will slap you, we don't need scripts to fix this for us
> during commit/build.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
>
> ---------------------------------------------------------------------
> 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
>
>
Re: [general] define pre-commit testing configs to gain the stability
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> If it turns out to be a big deal, we can simply add a pre-commit target
> to the build that checks for things like that. It could also check for
> things like tabs. If possible, it could be a pre-commit hook for svn,
> but if not, in the build would be useful for those creating patches...
Jeepers! Just hit return at the end of the file. If you screw-up the
build system will slap you, we don't need scripts to fix this for us
during commit/build.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mike Ringrose <mi...@gmail.com>.
Here's a reference that I found.
http://gcc.gnu.org/ml/gcc/2003-11/msg01568.html
Here's a link to ISO C 1999 standard. Look at section 5.1.1.2, item #3.
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
Mike Ringrose
On 10/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Weldon Washburn wrote:
>
> >
> >> Have you tried it on another version?
> >> No I have not tried it on another version. If Mike Ringrose is correct
> >> about the ISO spec, the basic problem is that MSVC compiler is not ISO
> >> compliant. I have hit this specific problem multiple times over the
> >> years.
> >> That is, code developed on windows laptop w/o a blank new line at the
> end
> >> will not compile on gcc.
> >
> >
> > No I have not tried it on another version. If Mike Ringrose is correct
> > about the ISO spec, the basic problem is that MSVC compiler is not ISO
> > compliant. I have hit this specific problem multiple times over the
> years.
> > That is, code developed on windows laptop w/o a blank new line at the
> end
> > will not compile on gcc.
> >
> > The real issue is that there are a bunch of "minor" incompatibilities
> > between MSVC and gcc. I would not recommend holding one's breath
> waiting
> > for them to go away. My approach to the above is to simply test on both
> > linux and windows before committing.
> >
>
> If it turns out to be a big deal, we can simply add a pre-commit target
> to the build that checks for things like that. It could also check for
> things like tabs. If possible, it could be a pre-commit hook for svn,
> but if not, in the build would be useful for those creating patches...
>
> geir
>
>
> ---------------------------------------------------------------------
> 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
>
>
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Weldon Washburn wrote:
>
>> Have you tried it on another version?
>> No I have not tried it on another version. If Mike Ringrose is correct
>> about the ISO spec, the basic problem is that MSVC compiler is not ISO
>> compliant. I have hit this specific problem multiple times over the
>> years.
>> That is, code developed on windows laptop w/o a blank new line at the end
>> will not compile on gcc.
>
>
> No I have not tried it on another version. If Mike Ringrose is correct
> about the ISO spec, the basic problem is that MSVC compiler is not ISO
> compliant. I have hit this specific problem multiple times over the years.
> That is, code developed on windows laptop w/o a blank new line at the end
> will not compile on gcc.
>
> The real issue is that there are a bunch of "minor" incompatibilities
> between MSVC and gcc. I would not recommend holding one's breath waiting
> for them to go away. My approach to the above is to simply test on both
> linux and windows before committing.
>
If it turns out to be a big deal, we can simply add a pre-commit target
to the build that checks for things like that. It could also check for
things like tabs. If possible, it could be a pre-commit hook for svn,
but if not, in the build would be useful for those creating patches...
geir
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x201 day of Apache Harmony Weldon Washburn wrote:
> On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> > Weldon Washburn wrote:
> > > On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>
> > >>
> > >>
> > >> Weldon Washburn wrote:
> > >> > A word of caution to those who are committing C/C++ code. There are
> > >> unique
> > >> > features of Microsoft C/C++ that will cause a build failure on Linux
> > >> and
> > >> > vice versa. For example, gcc expects that the end of a C/C++ file is
> > a
> > >> > blank line. Microsoft does not.
> > >>
> > >> That's gotta be a bug. What version are you using?
> > >
> > >
> > > gcc 3.4.5. If its a bug, its unlikely we will fix gcc or wait for gcc
> > > to be
> > > fixed.
>
>
>
> > Have you tried it on another version?
> > No I have not tried it on another version. If Mike Ringrose is correct
> > about the ISO spec, the basic problem is that MSVC compiler is not ISO
> > compliant. I have hit this specific problem multiple times over the years.
> > That is, code developed on windows laptop w/o a blank new line at the end
> > will not compile on gcc.
>
>
> No I have not tried it on another version. If Mike Ringrose is correct
> about the ISO spec, the basic problem is that MSVC compiler is not ISO
> compliant. I have hit this specific problem multiple times over the years.
> That is, code developed on windows laptop w/o a blank new line at the end
> will not compile on gcc.
>
> The real issue is that there are a bunch of "minor" incompatibilities
> between MSVC and gcc. I would not recommend holding one's breath waiting
> for them to go away. My approach to the above is to simply test on both
> linux and windows before committing.
+1 for checking on both win&lin as a pre-commit (for C/C++). I recall
many incompatibilities between the two compilers, so, checking both
platforms is less of a burden than it is a benefit.
Checking on various toolchains (gcc version, libc, binutils) seems not
so obviously helpful to me. Because it is a heavy check, not giving
much in terms of bug isolation.
There are various real-life situations, when a toolchain version can
influence on stability, but I think, they are not so common and are
not worth the effort of checking before each commit.
On compilation problems: let's take a more restrictive GCC (4.1?) and
that would cook all compilation for us on Linux.
--
Egor Pasko, Intel Managed Runtime 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Weldon Washburn <we...@gmail.com>.
On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Weldon Washburn wrote:
> > On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>
> >>
> >>
> >> Weldon Washburn wrote:
> >> > A word of caution to those who are committing C/C++ code. There are
> >> unique
> >> > features of Microsoft C/C++ that will cause a build failure on Linux
> >> and
> >> > vice versa. For example, gcc expects that the end of a C/C++ file is
> a
> >> > blank line. Microsoft does not.
> >>
> >> That's gotta be a bug. What version are you using?
> >
> >
> > gcc 3.4.5. If its a bug, its unlikely we will fix gcc or wait for gcc
> > to be
> > fixed.
> Have you tried it on another version?
> No I have not tried it on another version. If Mike Ringrose is correct
> about the ISO spec, the basic problem is that MSVC compiler is not ISO
> compliant. I have hit this specific problem multiple times over the years.
> That is, code developed on windows laptop w/o a blank new line at the end
> will not compile on gcc.
No I have not tried it on another version. If Mike Ringrose is correct
about the ISO spec, the basic problem is that MSVC compiler is not ISO
compliant. I have hit this specific problem multiple times over the years.
That is, code developed on windows laptop w/o a blank new line at the end
will not compile on gcc.
The real issue is that there are a bunch of "minor" incompatibilities
between MSVC and gcc. I would not recommend holding one's breath waiting
for them to go away. My approach to the above is to simply test on both
linux and windows before committing.
T
--
> Weldon Washburn
> Intel Middleware Products Division
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Weldon Washburn wrote:
> On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>>
>>
>> Weldon Washburn wrote:
>> > A word of caution to those who are committing C/C++ code. There are
>> unique
>> > features of Microsoft C/C++ that will cause a build failure on Linux
>> and
>> > vice versa. For example, gcc expects that the end of a C/C++ file is a
>> > blank line. Microsoft does not.
>>
>> That's gotta be a bug. What version are you using?
>
>
> gcc 3.4.5. If its a bug, its unlikely we will fix gcc or wait for gcc
> to be
> fixed.
Have you tried it on another version?
The pragmatic approach would be to simply open the *.cpp files, go
> to the bottom and hit the "return" key. The point is simply beware that
> committing even platform independent code may break the build/test on an
> untested platform. The biggest disconnect seems to be between (surprise)
> windows and linux. Testing on one of each will go a long way to reducing
> problems.
>
>>
>> > To reduce svn HEAD problems, it would be great if committers can test
>> all
>> > commits on at least some windows box and some linux box.
>> >
>> >
>> > On 10/9/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>> >>
>> >> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> >> > Hi Pavel,
>> >> >
>> >> > I'm sorry I did not catch how for example Nathan's commits will be
>> >> checked
>> >> > on the configurations he does not have?
>> >>
>> >> Since we have the problem with diversity of the hardware the
>> >> committers own the following procedure might be reasonable:
>> >>
>> >> - If the commit does not depend on platform/OS, for example, a patch
>> >> to some OS-independent Java API, he checks it only Windows with
>> >> definite configuration.
>> >>
>> >> - If the commit may depend on the platform, for example, a patch to
>> >> the system-dependent native code, he checks it on Windows with
>> >> definite configuration and ask another committer to check it on other
>> >> system.
>> >>
>> >> >
>> >> > Thanks,
>> >> > Mikhail
>> >> >
>> >>
>> >> Thanks,
>> >> Pavel
>> >>
>> >>
>> >>
>> >> --
>> >> Weldon Washburn
>> >> 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
this I can believe :)
Mike Ringrose wrote:
> If I remember correctly doesn't gcc only issue a warning. I believe the ISO
> C standard states that there shall be a new line at the end of a non-empty
> file.
>
> On 10/12/06, Weldon Washburn <we...@gmail.com> wrote:
>>
>> On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >
>> >
>> >
>> > Weldon Washburn wrote:
>> > > A word of caution to those who are committing C/C++ code. There are
>> > unique
>> > > features of Microsoft C/C++ that will cause a build failure on Linux
>> and
>> > > vice versa. For example, gcc expects that the end of a C/C++ file is
>> a
>> > > blank line. Microsoft does not.
>> >
>> > That's gotta be a bug. What version are you using?
>>
>>
>> gcc 3.4.5. If its a bug, its unlikely we will fix gcc or wait for gcc to
>> be
>> fixed. The pragmatic approach would be to simply open the *.cpp
>> files, go
>> to the bottom and hit the "return" key. The point is simply beware that
>> committing even platform independent code may break the build/test on an
>> untested platform. The biggest disconnect seems to be between (surprise)
>> windows and linux. Testing on one of each will go a long way to reducing
>> problems.
>>
>> >
>> > > To reduce svn HEAD problems, it would be great if committers can test
>> > all
>> > > commits on at least some windows box and some linux box.
>> > >
>> > >
>> > > On 10/9/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>> > >>
>> > >> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> > >> > Hi Pavel,
>> > >> >
>> > >> > I'm sorry I did not catch how for example Nathan's commits will be
>> > >> checked
>> > >> > on the configurations he does not have?
>> > >>
>> > >> Since we have the problem with diversity of the hardware the
>> > >> committers own the following procedure might be reasonable:
>> > >>
>> > >> - If the commit does not depend on platform/OS, for example, a patch
>> > >> to some OS-independent Java API, he checks it only Windows with
>> > >> definite configuration.
>> > >>
>> > >> - If the commit may depend on the platform, for example, a patch to
>> > >> the system-dependent native code, he checks it on Windows with
>> > >> definite configuration and ask another committer to check it on
>> other
>> > >> system.
>> > >>
>> > >> >
>> > >> > Thanks,
>> > >> > Mikhail
>> > >> >
>> > >>
>> > >> Thanks,
>> > >> Pavel
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Weldon Washburn
>> > >> 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
>> >
>> >
>>
>>
>> --
>> Weldon Washburn
>> 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mikhail Fursov <mi...@gmail.com>.
Once every file is started with /* */ like comment (Apache license) the line
endings are not a problem :)
On 13 Oct 2006 14:05:17 +0700, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x201 day of Apache Harmony Mike Ringrose wrote:
> > If I remember correctly doesn't gcc only issue a warning. I believe the
> ISO
> > C standard states that there shall be a new line at the end of a
> non-empty
> > file.
>
> we treat warnings as errors in DRLVM, which is useful. Is there an
> option in GCC not to warn on this specific line-ending
> problem? Unfortunately, I did not find any.
>
> > On 10/12/06, Weldon Washburn <we...@gmail.com> wrote:
> > >
> > > On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >
> > > >
> > > >
> > > > Weldon Washburn wrote:
> > > > > A word of caution to those who are committing C/C++ code. There
> are
> > > > unique
> > > > > features of Microsoft C/C++ that will cause a build failure on
> Linux
> > > and
> > > > > vice versa. For example, gcc expects that the end of a C/C++ file
> is
> > > a
> > > > > blank line. Microsoft does not.
> > > >
> > > > That's gotta be a bug. What version are you using?
> > >
> > >
> > > gcc 3.4.5. If its a bug, its unlikely we will fix gcc or wait for gcc
> to
> > > be
> > > fixed. The pragmatic approach would be to simply open the *.cpp
> files, go
> > > to the bottom and hit the "return" key. The point is simply beware
> that
> > > committing even platform independent code may break the build/test on
> an
> > > untested platform. The biggest disconnect seems to be between
> (surprise)
> > > windows and linux. Testing on one of each will go a long way to
> reducing
> > > problems.
> > >
> > > >
> > > > > To reduce svn HEAD problems, it would be great if committers can
> test
> > > > all
> > > > > commits on at least some windows box and some linux box.
> > > > >
> > > > >
> > > > > On 10/9/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > > > >>
> > > > >> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > > >> > Hi Pavel,
> > > > >> >
> > > > >> > I'm sorry I did not catch how for example Nathan's commits will
> be
> > > > >> checked
> > > > >> > on the configurations he does not have?
> > > > >>
> > > > >> Since we have the problem with diversity of the hardware the
> > > > >> committers own the following procedure might be reasonable:
> > > > >>
> > > > >> - If the commit does not depend on platform/OS, for example, a
> patch
> > > > >> to some OS-independent Java API, he checks it only Windows with
> > > > >> definite configuration.
> > > > >>
> > > > >> - If the commit may depend on the platform, for example, a patch
> to
> > > > >> the system-dependent native code, he checks it on Windows with
> > > > >> definite configuration and ask another committer to check it on
> other
> > > > >> system.
> > > > >>
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Mikhail
> > > > >> >
> > > > >>
> > > > >> Thanks,
> > > > >> Pavel
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Weldon Washburn
> > > > >> 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
> > > >
> > > >
> > >
> > >
> > > --
> > > Weldon Washburn
> > > Intel Middleware Products Division
> > >
> > >
>
> --
> Egor Pasko, Intel Managed Runtime 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
>
>
--
Mikhail Fursov
Re: [general] define pre-commit testing configs to gain the stability
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x201 day of Apache Harmony Mike Ringrose wrote:
> If I remember correctly doesn't gcc only issue a warning. I believe the ISO
> C standard states that there shall be a new line at the end of a non-empty
> file.
we treat warnings as errors in DRLVM, which is useful. Is there an
option in GCC not to warn on this specific line-ending
problem? Unfortunately, I did not find any.
> On 10/12/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >
> > >
> > >
> > > Weldon Washburn wrote:
> > > > A word of caution to those who are committing C/C++ code. There are
> > > unique
> > > > features of Microsoft C/C++ that will cause a build failure on Linux
> > and
> > > > vice versa. For example, gcc expects that the end of a C/C++ file is
> > a
> > > > blank line. Microsoft does not.
> > >
> > > That's gotta be a bug. What version are you using?
> >
> >
> > gcc 3.4.5. If its a bug, its unlikely we will fix gcc or wait for gcc to
> > be
> > fixed. The pragmatic approach would be to simply open the *.cpp files, go
> > to the bottom and hit the "return" key. The point is simply beware that
> > committing even platform independent code may break the build/test on an
> > untested platform. The biggest disconnect seems to be between (surprise)
> > windows and linux. Testing on one of each will go a long way to reducing
> > problems.
> >
> > >
> > > > To reduce svn HEAD problems, it would be great if committers can test
> > > all
> > > > commits on at least some windows box and some linux box.
> > > >
> > > >
> > > > On 10/9/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > > >>
> > > >> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > >> > Hi Pavel,
> > > >> >
> > > >> > I'm sorry I did not catch how for example Nathan's commits will be
> > > >> checked
> > > >> > on the configurations he does not have?
> > > >>
> > > >> Since we have the problem with diversity of the hardware the
> > > >> committers own the following procedure might be reasonable:
> > > >>
> > > >> - If the commit does not depend on platform/OS, for example, a patch
> > > >> to some OS-independent Java API, he checks it only Windows with
> > > >> definite configuration.
> > > >>
> > > >> - If the commit may depend on the platform, for example, a patch to
> > > >> the system-dependent native code, he checks it on Windows with
> > > >> definite configuration and ask another committer to check it on other
> > > >> system.
> > > >>
> > > >> >
> > > >> > Thanks,
> > > >> > Mikhail
> > > >> >
> > > >>
> > > >> Thanks,
> > > >> Pavel
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Weldon Washburn
> > > >> 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
> > >
> > >
> >
> >
> > --
> > Weldon Washburn
> > Intel Middleware Products Division
> >
> >
--
Egor Pasko, Intel Managed Runtime 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mike Ringrose <mi...@gmail.com>.
If I remember correctly doesn't gcc only issue a warning. I believe the ISO
C standard states that there shall be a new line at the end of a non-empty
file.
On 10/12/06, Weldon Washburn <we...@gmail.com> wrote:
>
> On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> >
> >
> > Weldon Washburn wrote:
> > > A word of caution to those who are committing C/C++ code. There are
> > unique
> > > features of Microsoft C/C++ that will cause a build failure on Linux
> and
> > > vice versa. For example, gcc expects that the end of a C/C++ file is
> a
> > > blank line. Microsoft does not.
> >
> > That's gotta be a bug. What version are you using?
>
>
> gcc 3.4.5. If its a bug, its unlikely we will fix gcc or wait for gcc to
> be
> fixed. The pragmatic approach would be to simply open the *.cpp files, go
> to the bottom and hit the "return" key. The point is simply beware that
> committing even platform independent code may break the build/test on an
> untested platform. The biggest disconnect seems to be between (surprise)
> windows and linux. Testing on one of each will go a long way to reducing
> problems.
>
> >
> > > To reduce svn HEAD problems, it would be great if committers can test
> > all
> > > commits on at least some windows box and some linux box.
> > >
> > >
> > > On 10/9/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > >>
> > >> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > >> > Hi Pavel,
> > >> >
> > >> > I'm sorry I did not catch how for example Nathan's commits will be
> > >> checked
> > >> > on the configurations he does not have?
> > >>
> > >> Since we have the problem with diversity of the hardware the
> > >> committers own the following procedure might be reasonable:
> > >>
> > >> - If the commit does not depend on platform/OS, for example, a patch
> > >> to some OS-independent Java API, he checks it only Windows with
> > >> definite configuration.
> > >>
> > >> - If the commit may depend on the platform, for example, a patch to
> > >> the system-dependent native code, he checks it on Windows with
> > >> definite configuration and ask another committer to check it on other
> > >> system.
> > >>
> > >> >
> > >> > Thanks,
> > >> > Mikhail
> > >> >
> > >>
> > >> Thanks,
> > >> Pavel
> > >>
> > >>
> > >>
> > >> --
> > >> Weldon Washburn
> > >> 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
> >
> >
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>
Re: [general] define pre-commit testing configs to gain the stability
Posted by Weldon Washburn <we...@gmail.com>.
On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Weldon Washburn wrote:
> > A word of caution to those who are committing C/C++ code. There are
> unique
> > features of Microsoft C/C++ that will cause a build failure on Linux and
> > vice versa. For example, gcc expects that the end of a C/C++ file is a
> > blank line. Microsoft does not.
>
> That's gotta be a bug. What version are you using?
gcc 3.4.5. If its a bug, its unlikely we will fix gcc or wait for gcc to be
fixed. The pragmatic approach would be to simply open the *.cpp files, go
to the bottom and hit the "return" key. The point is simply beware that
committing even platform independent code may break the build/test on an
untested platform. The biggest disconnect seems to be between (surprise)
windows and linux. Testing on one of each will go a long way to reducing
problems.
>
> > To reduce svn HEAD problems, it would be great if committers can test
> all
> > commits on at least some windows box and some linux box.
> >
> >
> > On 10/9/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> >>
> >> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >> > Hi Pavel,
> >> >
> >> > I'm sorry I did not catch how for example Nathan's commits will be
> >> checked
> >> > on the configurations he does not have?
> >>
> >> Since we have the problem with diversity of the hardware the
> >> committers own the following procedure might be reasonable:
> >>
> >> - If the commit does not depend on platform/OS, for example, a patch
> >> to some OS-independent Java API, he checks it only Windows with
> >> definite configuration.
> >>
> >> - If the commit may depend on the platform, for example, a patch to
> >> the system-dependent native code, he checks it on Windows with
> >> definite configuration and ask another committer to check it on other
> >> system.
> >>
> >> >
> >> > Thanks,
> >> > Mikhail
> >> >
> >>
> >> Thanks,
> >> Pavel
> >>
> >>
> >>
> >> --
> >> Weldon Washburn
> >> 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
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Weldon Washburn wrote:
> A word of caution to those who are committing C/C++ code. There are unique
> features of Microsoft C/C++ that will cause a build failure on Linux and
> vice versa. For example, gcc expects that the end of a C/C++ file is a
> blank line. Microsoft does not.
That's gotta be a bug. What version are you using?
>
> To reduce svn HEAD problems, it would be great if committers can test all
> commits on at least some windows box and some linux box.
>
>
> On 10/9/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>>
>> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> > Hi Pavel,
>> >
>> > I'm sorry I did not catch how for example Nathan's commits will be
>> checked
>> > on the configurations he does not have?
>>
>> Since we have the problem with diversity of the hardware the
>> committers own the following procedure might be reasonable:
>>
>> - If the commit does not depend on platform/OS, for example, a patch
>> to some OS-independent Java API, he checks it only Windows with
>> definite configuration.
>>
>> - If the commit may depend on the platform, for example, a patch to
>> the system-dependent native code, he checks it on Windows with
>> definite configuration and ask another committer to check it on other
>> system.
>>
>> >
>> > Thanks,
>> > Mikhail
>> >
>>
>> Thanks,
>> Pavel
>>
>>
>>
>> --
>> Weldon Washburn
>> 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Weldon Washburn <we...@gmail.com>.
A word of caution to those who are committing C/C++ code. There are unique
features of Microsoft C/C++ that will cause a build failure on Linux and
vice versa. For example, gcc expects that the end of a C/C++ file is a
blank line. Microsoft does not.
To reduce svn HEAD problems, it would be great if committers can test all
commits on at least some windows box and some linux box.
On 10/9/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>
> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > Hi Pavel,
> >
> > I'm sorry I did not catch how for example Nathan's commits will be
> checked
> > on the configurations he does not have?
>
> Since we have the problem with diversity of the hardware the
> committers own the following procedure might be reasonable:
>
> - If the commit does not depend on platform/OS, for example, a patch
> to some OS-independent Java API, he checks it only Windows with
> definite configuration.
>
> - If the commit may depend on the platform, for example, a patch to
> the system-dependent native code, he checks it on Windows with
> definite configuration and ask another committer to check it on other
> system.
>
> >
> > Thanks,
> > Mikhail
> >
>
> Thanks,
> Pavel
>
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
Re: [general] define pre-commit testing configs to gain the stability
Posted by Alexey Petrenko <al...@gmail.com>.
Yes, It is reasonable and obvious.
And I believe that committers are using it already.
SY, Alexey
2006/10/10, Pavel Ozhdikhin <pa...@gmail.com>:
> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > Hi Pavel,
> >
> > I'm sorry I did not catch how for example Nathan's commits will be checked
> > on the configurations he does not have?
>
> Since we have the problem with diversity of the hardware the
> committers own the following procedure might be reasonable:
>
> - If the commit does not depend on platform/OS, for example, a patch
> to some OS-independent Java API, he checks it only Windows with
> definite configuration.
>
> - If the commit may depend on the platform, for example, a patch to
> the system-dependent native code, he checks it on Windows with
> definite configuration and ask another committer to check it on other
> system.
>
> >
> > Thanks,
> > Mikhail
> >
>
> Thanks,
> Pavel
>
> > 2006/10/9, Pavel Ozhdikhin <pa...@gmail.com>:
> > > On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > > > Rana Dasgupta wrote:
> > > > > We need to check both release and debug builds...the binaries and timing
> > > > > characteristics are too different. At this immediate stage of the
> > > > > project, I
> > > > > would suggest leaving out EM64T as part of mandatory testing( unless it is
> > > > > EM64T specific functionality, eg., codegen ). Too few contributors and
> > > > > committers have access to it. We are not yet at a stage where we can make
> > > > > this mandatory.
> > > > >
> > > > > If possible all submissions should be tested( by submitters ) on all the
> > > > > combinations identified . It is actually more urgent for submitters to do
> > > > > this. We should stop patches by email. Also, at this point, it is an honor
> > > > > system, we can't attach 6 before and after test logs to each JIRA
> > > > > submission. The committer could randomly check on one or more combination,
> > > > > ...the more the better obviously.
> > > > >
> > > > > In some cases, submissions will be platform specific ( eg., very new code
> > > > > like GC V5, platform specific bug fixes or a simple case of developer not
> > > > > having all the machines ). I would leave these to the committers'
> > > > > discretion.
> > > >
> > > > Mandating that patches are pre-tested on a wide variety of machines is
> > > > not conducive to building a broad community of contributors since very
> > > > few people have access to all the machines and configurations we are
> > > > interested in. I'd much prefer that we work optimistically and have
> > > > lots of people regularly building and testing the code to get the
> > > > broadest possible coverage. We can backtrack if problems arise.
> > >
> > > Even is a committer does't have a wide variety of machines I think we
> > > can still mandate that his/her commits are checked on the right
> > > configuration. If the majority works on GCC 4.0.3 checking the patch
> > > on GCC 3.3.2 might not reveal the problems. Regular testing will, but
> > > the time spend on backtracking is lost. The proposal is not only about
> > > variety of configurations but is also about configurations themselves.
> > > Rana proposed to exclude EM64T and add debug configs, so for now the
> > > list is following:
> > >
> > > - Windows / IA32 / MSVS .NET 2003 / release
> > > - Windows / IA32 / MSVS .NET 2003 / debug
> > > - Linux / IA32 / GCC 4.0.3 / release
> > > - Linux / IA32 / GCC 4.0.3 / debug
> > > - Linux / EM64T / GCC 4.0.3 / release
> > > - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> > > but at least Geir has a machine)
> > >
> > > Assuming you are testing you commits on one of the machines above, do
> > > you agree it make sense all committers to use the same configuration?
> > > For example, if you use Linux/IA32 and another committer uses
> > > Linux/IA32, do you agree that it makes sense to use the same compiler
> > > versions for pre-commit testing?
> > >
> > > Contributors are still free to check their patches whenever they want
> > > or don't test them at all, but they should know what to expect from
> > > the committers.
> > >
> > > Thanks,
> > > Pavel
> > >
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > > > --
> > > >
> > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > IBM Java technology centre, UK.
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
>
>
--
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Alexei Zakharov <al...@gmail.com>.
Please note that the concrete version of OS is also important. I.e.
something that works on WinXP can break on ws2003 or win2000. I have
already seen such problems.
Regards,
2006/10/10, Pavel Ozhdikhin <pa...@gmail.com>:
> On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > Hi Pavel,
> >
> > I'm sorry I did not catch how for example Nathan's commits will be checked
> > on the configurations he does not have?
>
> Since we have the problem with diversity of the hardware the
> committers own the following procedure might be reasonable:
>
> - If the commit does not depend on platform/OS, for example, a patch
> to some OS-independent Java API, he checks it only Windows with
> definite configuration.
>
> - If the commit may depend on the platform, for example, a patch to
> the system-dependent native code, he checks it on Windows with
> definite configuration and ask another committer to check it on other
> system.
>
> >
> > Thanks,
> > Mikhail
> >
>
> Thanks,
> Pavel
>
> > 2006/10/9, Pavel Ozhdikhin <pa...@gmail.com>:
> > > On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > > > Rana Dasgupta wrote:
> > > > > We need to check both release and debug builds...the binaries and timing
> > > > > characteristics are too different. At this immediate stage of the
> > > > > project, I
> > > > > would suggest leaving out EM64T as part of mandatory testing( unless it is
> > > > > EM64T specific functionality, eg., codegen ). Too few contributors and
> > > > > committers have access to it. We are not yet at a stage where we can make
> > > > > this mandatory.
> > > > >
> > > > > If possible all submissions should be tested( by submitters ) on all the
> > > > > combinations identified . It is actually more urgent for submitters to do
> > > > > this. We should stop patches by email. Also, at this point, it is an honor
> > > > > system, we can't attach 6 before and after test logs to each JIRA
> > > > > submission. The committer could randomly check on one or more combination,
> > > > > ...the more the better obviously.
> > > > >
> > > > > In some cases, submissions will be platform specific ( eg., very new code
> > > > > like GC V5, platform specific bug fixes or a simple case of developer not
> > > > > having all the machines ). I would leave these to the committers'
> > > > > discretion.
> > > >
> > > > Mandating that patches are pre-tested on a wide variety of machines is
> > > > not conducive to building a broad community of contributors since very
> > > > few people have access to all the machines and configurations we are
> > > > interested in. I'd much prefer that we work optimistically and have
> > > > lots of people regularly building and testing the code to get the
> > > > broadest possible coverage. We can backtrack if problems arise.
> > >
> > > Even is a committer does't have a wide variety of machines I think we
> > > can still mandate that his/her commits are checked on the right
> > > configuration. If the majority works on GCC 4.0.3 checking the patch
> > > on GCC 3.3.2 might not reveal the problems. Regular testing will, but
> > > the time spend on backtracking is lost. The proposal is not only about
> > > variety of configurations but is also about configurations themselves.
> > > Rana proposed to exclude EM64T and add debug configs, so for now the
> > > list is following:
> > >
> > > - Windows / IA32 / MSVS .NET 2003 / release
> > > - Windows / IA32 / MSVS .NET 2003 / debug
> > > - Linux / IA32 / GCC 4.0.3 / release
> > > - Linux / IA32 / GCC 4.0.3 / debug
> > > - Linux / EM64T / GCC 4.0.3 / release
> > > - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> > > but at least Geir has a machine)
> > >
> > > Assuming you are testing you commits on one of the machines above, do
> > > you agree it make sense all committers to use the same configuration?
> > > For example, if you use Linux/IA32 and another committer uses
> > > Linux/IA32, do you agree that it makes sense to use the same compiler
> > > versions for pre-commit testing?
> > >
> > > Contributors are still free to check their patches whenever they want
> > > or don't test them at all, but they should know what to expect from
> > > the committers.
> > >
> > > Thanks,
> > > Pavel
> > >
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > > > --
> > > >
> > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > IBM Java technology centre, UK.
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
>
>
--
Alexei Zakharov,
Intel Middleware Product 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 10/9/06, Mikhail Loenko <ml...@gmail.com> wrote:
> Hi Pavel,
>
> I'm sorry I did not catch how for example Nathan's commits will be checked
> on the configurations he does not have?
Since we have the problem with diversity of the hardware the
committers own the following procedure might be reasonable:
- If the commit does not depend on platform/OS, for example, a patch
to some OS-independent Java API, he checks it only Windows with
definite configuration.
- If the commit may depend on the platform, for example, a patch to
the system-dependent native code, he checks it on Windows with
definite configuration and ask another committer to check it on other
system.
>
> Thanks,
> Mikhail
>
Thanks,
Pavel
> 2006/10/9, Pavel Ozhdikhin <pa...@gmail.com>:
> > On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > > Rana Dasgupta wrote:
> > > > We need to check both release and debug builds...the binaries and timing
> > > > characteristics are too different. At this immediate stage of the
> > > > project, I
> > > > would suggest leaving out EM64T as part of mandatory testing( unless it is
> > > > EM64T specific functionality, eg., codegen ). Too few contributors and
> > > > committers have access to it. We are not yet at a stage where we can make
> > > > this mandatory.
> > > >
> > > > If possible all submissions should be tested( by submitters ) on all the
> > > > combinations identified . It is actually more urgent for submitters to do
> > > > this. We should stop patches by email. Also, at this point, it is an honor
> > > > system, we can't attach 6 before and after test logs to each JIRA
> > > > submission. The committer could randomly check on one or more combination,
> > > > ...the more the better obviously.
> > > >
> > > > In some cases, submissions will be platform specific ( eg., very new code
> > > > like GC V5, platform specific bug fixes or a simple case of developer not
> > > > having all the machines ). I would leave these to the committers'
> > > > discretion.
> > >
> > > Mandating that patches are pre-tested on a wide variety of machines is
> > > not conducive to building a broad community of contributors since very
> > > few people have access to all the machines and configurations we are
> > > interested in. I'd much prefer that we work optimistically and have
> > > lots of people regularly building and testing the code to get the
> > > broadest possible coverage. We can backtrack if problems arise.
> >
> > Even is a committer does't have a wide variety of machines I think we
> > can still mandate that his/her commits are checked on the right
> > configuration. If the majority works on GCC 4.0.3 checking the patch
> > on GCC 3.3.2 might not reveal the problems. Regular testing will, but
> > the time spend on backtracking is lost. The proposal is not only about
> > variety of configurations but is also about configurations themselves.
> > Rana proposed to exclude EM64T and add debug configs, so for now the
> > list is following:
> >
> > - Windows / IA32 / MSVS .NET 2003 / release
> > - Windows / IA32 / MSVS .NET 2003 / debug
> > - Linux / IA32 / GCC 4.0.3 / release
> > - Linux / IA32 / GCC 4.0.3 / debug
> > - Linux / EM64T / GCC 4.0.3 / release
> > - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> > but at least Geir has a machine)
> >
> > Assuming you are testing you commits on one of the machines above, do
> > you agree it make sense all committers to use the same configuration?
> > For example, if you use Linux/IA32 and another committer uses
> > Linux/IA32, do you agree that it makes sense to use the same compiler
> > versions for pre-commit testing?
> >
> > Contributors are still free to check their patches whenever they want
> > or don't test them at all, but they should know what to expect from
> > the committers.
> >
> > Thanks,
> > Pavel
> >
> > >
> > > Regards,
> > > Tim
> > >
> > > --
> > >
> > > Tim Ellison (t.p.ellison@gmail.com)
> > > IBM Java technology centre, UK.
> > >
> > > ---------------------------------------------------------------------
> > > 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Pavel,
I'm sorry I did not catch how for example Nathan's commits will be checked
on the configurations he does not have?
Thanks,
Mikhail
2006/10/9, Pavel Ozhdikhin <pa...@gmail.com>:
> On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> > Rana Dasgupta wrote:
> > > We need to check both release and debug builds...the binaries and timing
> > > characteristics are too different. At this immediate stage of the
> > > project, I
> > > would suggest leaving out EM64T as part of mandatory testing( unless it is
> > > EM64T specific functionality, eg., codegen ). Too few contributors and
> > > committers have access to it. We are not yet at a stage where we can make
> > > this mandatory.
> > >
> > > If possible all submissions should be tested( by submitters ) on all the
> > > combinations identified . It is actually more urgent for submitters to do
> > > this. We should stop patches by email. Also, at this point, it is an honor
> > > system, we can't attach 6 before and after test logs to each JIRA
> > > submission. The committer could randomly check on one or more combination,
> > > ...the more the better obviously.
> > >
> > > In some cases, submissions will be platform specific ( eg., very new code
> > > like GC V5, platform specific bug fixes or a simple case of developer not
> > > having all the machines ). I would leave these to the committers'
> > > discretion.
> >
> > Mandating that patches are pre-tested on a wide variety of machines is
> > not conducive to building a broad community of contributors since very
> > few people have access to all the machines and configurations we are
> > interested in. I'd much prefer that we work optimistically and have
> > lots of people regularly building and testing the code to get the
> > broadest possible coverage. We can backtrack if problems arise.
>
> Even is a committer does't have a wide variety of machines I think we
> can still mandate that his/her commits are checked on the right
> configuration. If the majority works on GCC 4.0.3 checking the patch
> on GCC 3.3.2 might not reveal the problems. Regular testing will, but
> the time spend on backtracking is lost. The proposal is not only about
> variety of configurations but is also about configurations themselves.
> Rana proposed to exclude EM64T and add debug configs, so for now the
> list is following:
>
> - Windows / IA32 / MSVS .NET 2003 / release
> - Windows / IA32 / MSVS .NET 2003 / debug
> - Linux / IA32 / GCC 4.0.3 / release
> - Linux / IA32 / GCC 4.0.3 / debug
> - Linux / EM64T / GCC 4.0.3 / release
> - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
> but at least Geir has a machine)
>
> Assuming you are testing you commits on one of the machines above, do
> you agree it make sense all committers to use the same configuration?
> For example, if you use Linux/IA32 and another committer uses
> Linux/IA32, do you agree that it makes sense to use the same compiler
> versions for pre-commit testing?
>
> Contributors are still free to check their patches whenever they want
> or don't test them at all, but they should know what to expect from
> the committers.
>
> Thanks,
> Pavel
>
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
> > ---------------------------------------------------------------------
> > 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 10/9/06, Tim Ellison <t....@gmail.com> wrote:
> Rana Dasgupta wrote:
> > We need to check both release and debug builds...the binaries and timing
> > characteristics are too different. At this immediate stage of the
> > project, I
> > would suggest leaving out EM64T as part of mandatory testing( unless it is
> > EM64T specific functionality, eg., codegen ). Too few contributors and
> > committers have access to it. We are not yet at a stage where we can make
> > this mandatory.
> >
> > If possible all submissions should be tested( by submitters ) on all the
> > combinations identified . It is actually more urgent for submitters to do
> > this. We should stop patches by email. Also, at this point, it is an honor
> > system, we can't attach 6 before and after test logs to each JIRA
> > submission. The committer could randomly check on one or more combination,
> > ...the more the better obviously.
> >
> > In some cases, submissions will be platform specific ( eg., very new code
> > like GC V5, platform specific bug fixes or a simple case of developer not
> > having all the machines ). I would leave these to the committers'
> > discretion.
>
> Mandating that patches are pre-tested on a wide variety of machines is
> not conducive to building a broad community of contributors since very
> few people have access to all the machines and configurations we are
> interested in. I'd much prefer that we work optimistically and have
> lots of people regularly building and testing the code to get the
> broadest possible coverage. We can backtrack if problems arise.
Even is a committer does't have a wide variety of machines I think we
can still mandate that his/her commits are checked on the right
configuration. If the majority works on GCC 4.0.3 checking the patch
on GCC 3.3.2 might not reveal the problems. Regular testing will, but
the time spend on backtracking is lost. The proposal is not only about
variety of configurations but is also about configurations themselves.
Rana proposed to exclude EM64T and add debug configs, so for now the
list is following:
- Windows / IA32 / MSVS .NET 2003 / release
- Windows / IA32 / MSVS .NET 2003 / debug
- Linux / IA32 / GCC 4.0.3 / release
- Linux / IA32 / GCC 4.0.3 / debug
- Linux / EM64T / GCC 4.0.3 / release
- Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable,
but at least Geir has a machine)
Assuming you are testing you commits on one of the machines above, do
you agree it make sense all committers to use the same configuration?
For example, if you use Linux/IA32 and another committer uses
Linux/IA32, do you agree that it makes sense to use the same compiler
versions for pre-commit testing?
Contributors are still free to check their patches whenever they want
or don't test them at all, but they should know what to expect from
the committers.
Thanks,
Pavel
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Tim Ellison <t....@gmail.com>.
Rana Dasgupta wrote:
> We need to check both release and debug builds...the binaries and timing
> characteristics are too different. At this immediate stage of the
> project, I
> would suggest leaving out EM64T as part of mandatory testing( unless it is
> EM64T specific functionality, eg., codegen ). Too few contributors and
> committers have access to it. We are not yet at a stage where we can make
> this mandatory.
>
> If possible all submissions should be tested( by submitters ) on all the
> combinations identified . It is actually more urgent for submitters to do
> this. We should stop patches by email. Also, at this point, it is an honor
> system, we can't attach 6 before and after test logs to each JIRA
> submission. The committer could randomly check on one or more combination,
> ...the more the better obviously.
>
> In some cases, submissions will be platform specific ( eg., very new code
> like GC V5, platform specific bug fixes or a simple case of developer not
> having all the machines ). I would leave these to the committers'
> discretion.
Mandating that patches are pre-tested on a wide variety of machines is
not conducive to building a broad community of contributors since very
few people have access to all the machines and configurations we are
interested in. I'd much prefer that we work optimistically and have
lots of people regularly building and testing the code to get the
broadest possible coverage. We can backtrack if problems arise.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Rana Dasgupta <rd...@gmail.com>.
On 10/6/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>
>
>
> >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.
>
>
> >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
>
> We need to check both release and debug builds...the binaries and timing
characteristics are too different. At this immediate stage of the project, I
would suggest leaving out EM64T as part of mandatory testing( unless it is
EM64T specific functionality, eg., codegen ). Too few contributors and
committers have access to it. We are not yet at a stage where we can make
this mandatory.
If possible all submissions should be tested( by submitters ) on all the
combinations identified . It is actually more urgent for submitters to do
this. We should stop patches by email. Also, at this point, it is an honor
system, we can't attach 6 before and after test logs to each JIRA
submission. The committer could randomly check on one or more combination,
...the more the better obviously.
In some cases, submissions will be platform specific ( eg., very new code
like GC V5, platform specific bug fixes or a simple case of developer not
having all the machines ). I would leave these to the committers'
discretion.
Thanks.
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 10/7/06, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> What would you do if you need to commit a patch to some Linux-specific
> code in VM?
> 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.
I meant "not even compiled on Linux", of course. :)
>
> On 10/7/06, Nathan Beyer <nb...@gmail.com> wrote:
> > I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence.
> >
> > On 10/6/06, Pavel Ozhdikhin <pa...@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 <al...@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 <pa...@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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 10/7/06, Alexey Petrenko <al...@gmail.com> wrote:
> 2006/10/6, Pavel Ozhdikhin <pa...@gmail.com>:
> > What would you do if you need to commit a patch to some Linux-specific
> > code in VM?
> And I do not have Linux?
> I will not commit this patch of course. And will ask another committer
> to do this.
Right, you won't commit patches that require checking on the platform
you don't have. This is not because the criteria require this, this is
because you understand that you can't test it properly. I propose that
we introduce the criteria which will support our common sense and make
our development more determined.
>
> Pavel, again. I understand your concern and I think that testing a
> patch different platforms is really good approach.
> But I'm afraid that it is unreal to set this as a requirement for all
> the commiters and all the patches.
I think this depends on the requirements. Would you agree for example,
to switch to a particular compiler version if all committers agree to
use it? This might be a first requirement.
>
> But this is should not be a big problem. Because we have a regression
> tests. So if one committer commits something on Linux and accidentally
> breaks something on Windows another community member will catch it.
The problem is that a concious contributor can not pass tests and
submit his/her patches until code is broken. Also a contributor can
not be sure passing all tests is enough to make sure the committer
will pass thesame tests with this patch. I'm not sure even that
currently all the committers use the same GCC version.
Anyway, thanks for your attention to the problem!
>
> > 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 <nb...@gmail.com> wrote:
> > > I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence.
> > >
> > > On 10/6/06, Pavel Ozhdikhin <pa...@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 <al...@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 <pa...@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
> >
> >
>
>
> --
> 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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Alexey Petrenko <al...@gmail.com>.
2006/10/6, Pavel Ozhdikhin <pa...@gmail.com>:
> What would you do if you need to commit a patch to some Linux-specific
> code in VM?
And I do not have Linux?
I will not commit this patch of course. And will ask another committer
to do this.
Pavel, again. I understand your concern and I think that testing a
patch different platforms is really good approach.
But I'm afraid that it is unreal to set this as a requirement for all
the commiters and all the patches.
But this is should not be a big problem. Because we have a regression
tests. So if one committer commits something on Linux and accidentally
breaks something on Windows another community member will catch 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 <nb...@gmail.com> wrote:
> > I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence.
> >
> > On 10/6/06, Pavel Ozhdikhin <pa...@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 <al...@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 <pa...@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
>
>
--
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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 <nb...@gmail.com> wrote:
>> I only have Windows/MSVC2003/IA32, if you're looking for anecdotal
>> evidence.
>>
>> On 10/6/06, Pavel Ozhdikhin <pa...@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 <al...@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 <pa...@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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
What would you do if you need to commit a patch to some Linux-specific
code in VM?
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 <nb...@gmail.com> wrote:
> I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence.
>
> On 10/6/06, Pavel Ozhdikhin <pa...@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 <al...@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 <pa...@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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Nathan Beyer <nb...@gmail.com>.
I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence.
On 10/6/06, Pavel Ozhdikhin <pa...@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 <al...@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 <pa...@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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Alexey Petrenko <al...@gmail.com>.
I'm also not sure that ALL the commiters has Windows and Linux at the
same time...
And Nathan is an example :)
SY, Alexey
2006/10/6, Pavel Ozhdikhin <pa...@gmail.com>:
> 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 <al...@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 <pa...@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
>
>
--
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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
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 <al...@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 <pa...@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
Re: [general] define pre-commit testing configs to gain the stability
Posted by Alexey Petrenko <al...@gmail.com>.
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 <pa...@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