harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [general] define pre-commit testing configs to gain the stability
Date Tue, 10 Oct 2006 12:06:32 GMT

On 10 October 2006 at 18:52, "Pavel Ozhdikhin" <pavel.ozhdikhin@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 <pavel.ozhdikhin@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 <mark.hindess@googlemail.com> wrote:
> > >
> > > On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <pavel.ozhdikhin@gmail.com>
>  wrote:
> > > > On 10/9/06, Tim Ellison <t.p.ellison@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


Mime
View raw message