On 10/9/06, Mikhail Loenko <mloenko@gmail.com> 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 <pavel.ozhdikhin@gmail.com>:
> > 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
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 (t.p.ellison@gmail.com)
> > > IBM Java technology centre, UK.
> > >
> > > ---------------------------------------------------------------------
> > > 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