On 10/10/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
On 10 October 2006 at 18:52, "Pavel Ozhdikhin" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
