On Oct 9, 2006, at 8:52 AM, Mark Hindess wrote:
On 9 October 2006 at 16:12, "Pavel Ozhdikhin"
<[EMAIL PROTECTED]> wrote:
On 10/9/06, Tim Ellison <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
