I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence.

On 10/6/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
Alexey,

No, I'm not sure the committers have all the configurations. I think
most of all have Windows and Linux IA32, but I doubt all of them have
EM64T. This is indeed the problem and I hope together we will find the
solution. For example, we may not require classlib commits to be
tested on EM64T for now, or check if Apache has machines for testing,
or we'll have a magic tool which will run EM64T tests for all
committers on some hidden machine etc. If finally we realize that it's
impossible to require EM64T testing at this time, we can delay this
particular config, but regarding remaining criteria I think we can
avoid many problems using primary target configs.

Thanks,
Pavel



On 10/6/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> Pavel,
>
> Your idea has sence. But... Are you sure that all the committers has
> all the mentioned configurations?
>
> SY, Alexey
>
> 2006/10/6, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
> > Hello all,
> >
> > This thread is about a way to improve stability in the environment of
> > growing patch flow in Harmony. Originally I though about DRLVM issues
> > but this may be helpful for classlib too.
> >
> > Currenly, before committing a patch a committer checks it on his
> > favorite configurations (I mean architecture, OS and compiler first of
> > all). Another committer checks another patch on a different set of
> > configurations. As a result, though both patches are tested, there is
> > no guarantee that they will work together on any configuration.
> >
> > If we agree on common testing configs we can make sure the Harmony
> > will be stable on at least this set of configurations. This does not
> > mean we won't fix problems on other configurations. The goal is to
> > gain and maintain general stability.
> >
> > Another benefit would be in faster adoption of patches. If
> > contributors could check their patches on the same configs as the
> > committers do, there would be less likely a particular patch is
> > rejected.
> >
> > I propose to work out a set of configs the committers will use to
> > check patches before committing them to SVN. We can start with a few
> > configs defining the platform, OS familly and the compiler used. When
> > we are sure the Harmony is stable we can add more configurations. IMO,
> > it would be reasonable to start with 3 configurations - one
> > configuration for each supported platform, for example:
> >
> > - Windows / IA32 / MSVS .NET 2003 / release
> > - Linux / IA32 / GCC 4.0.3 / release
> > - Linux / EM64T / GCC 4.0.3 / release
> >
> > There may be a contrary point - let's everyone use it's own platform -
> > such way we'll discover bugs earlier. I think this might work good in
> > a smaller project. The Harmony is quite a big child already and trying
> > to kill all the birds we may chase them for ages.
> >
> > I'd be happy if we converge on the set of our primary target configs here.
> >
> > Thank you
> > Pavel Ozhdikhin
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> 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]

Reply via email to