Pavel Ozhdikhin wrote:
What would you do if you need to commit a patch to some Linux-specific
code in VM?

Ask someone w/ a linux box to check it.

The commit criteria my be either as simple as a list of configs or
have also some exclusions. For example, there is no much sense to test
on Linux a patch for a source file which is not even compiled on
Windows.

On 10/7/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
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]



---------------------------------------------------------------------
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