On 10/7/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
2006/10/6, Pavel Ozhdikhin <[EMAIL PROTECTED]>: > What would you do if you need to commit a patch to some Linux-specific > code in VM? And I do not have Linux? I will not commit this patch of course. And will ask another committer to do this.
Right, you won't commit patches that require checking on the platform you don't have. This is not because the criteria require this, this is because you understand that you can't test it properly. I propose that we introduce the criteria which will support our common sense and make our development more determined.
Pavel, again. I understand your concern and I think that testing a patch different platforms is really good approach. But I'm afraid that it is unreal to set this as a requirement for all the commiters and all the patches.
I think this depends on the requirements. Would you agree for example, to switch to a particular compiler version if all committers agree to use it? This might be a first requirement.
But this is should not be a big problem. Because we have a regression tests. So if one committer commits something on Linux and accidentally breaks something on Windows another community member will catch it.
The problem is that a concious contributor can not pass tests and submit his/her patches until code is broken. Also a contributor can not be sure passing all tests is enough to make sure the committer will pass thesame tests with this patch. I'm not sure even that currently all the committers use the same GCC version. Anyway, thanks for your attention to the problem!
> 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] > > -- 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]
