You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/10/09 14:52:50 UTC
Re: [general] define pre-commit testing configs to gain the stability
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 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