harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [general] define pre-commit testing configs to gain the stability
Date Tue, 10 Oct 2006 12:29:06 GMT
On the 0x1FE day of Apache Harmony Pavel Ozhdikhin wrote:
> On 10/10/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
> >
> > 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. ;-)
> 
> 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 <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
> >
> >
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message