Please note that the concrete version of OS is also important. I.e. something that works on WinXP can break on ws2003 or win2000. I have already seen such problems.
Regards, 2006/10/10, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
On 10/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Hi Pavel, > > I'm sorry I did not catch how for example Nathan's commits will be checked > on the configurations he does not have? Since we have the problem with diversity of the hardware the committers own the following procedure might be reasonable: - If the commit does not depend on platform/OS, for example, a patch to some OS-independent Java API, he checks it only Windows with definite configuration. - If the commit may depend on the platform, for example, a patch to the system-dependent native code, he checks it on Windows with definite configuration and ask another committer to check it on other system. > > Thanks, > Mikhail > Thanks, Pavel > 2006/10/9, Pavel Ozhdikhin <[EMAIL PROTECTED]>: > > 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 is > > > > 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 honor > > > > 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. > > > > 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. 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) > > > > 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? > > 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? > > > > 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. > > > > Thanks, > > Pavel > > > > > > > > Regards, > > > Tim > > > > > > -- > > > > > > Tim Ellison ([EMAIL PROTECTED]) > > > IBM Java technology centre, UK. > > > > > > --------------------------------------------------------------------- > > > 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]
-- Alexei Zakharov, Intel Middleware Product Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
