harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [general] define pre-commit testing configs to gain the stability
Date Tue, 10 Oct 2006 11:52:22 GMT
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 <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
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


Mime
View raw message