On 21 June 2017 at 12:23, Bill Fischofer <[email protected]> wrote: > ODP is fairly open-ended in this regard because in theory we're only > dependent on > > - A C99-conforming compiler > - A platform that supports a reasonably recent Linux kernel > > Today we do test on 32 and 64 bit systems, and try to support both GCC > and clang, however as newer versions of these tools get released we > sometimes encounter problems. The same is true with older releases. We > try to accommodate, especially when the fix to support a wider range > of tools and platforms is relatively straightforward. > > It's not possible to test exhaustively on every possible combination > so when problems occur we open and fix bugs. However, once we fix a > bug we prefer to fix it only once, which means that in-flight patches > should be checked to see if they have a similar problem and should be > revised to avoid that problem as well. That way we don't fix the same > problem multiple times. > Agree. For anyone to submit a patch, they need to have a reference of what needs to be done. Scalable scheduler is an example, where we have been discovering at every patch that there is a new thing that needs to be done to accept the patch. If it was known upfront, we can work on them from day 1. This sets up the expectation and saves time for everyone, knowing that the patch works for this minimum acceptance criteria. For ex: I do not know how many times you have tried to compile the code and discovered that it does not compile. I would like to avoid those problems.
> > On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli > <[email protected]> wrote: >> Along with this, we need to standardize 32b/64b compilations and the >> platforms on which we run the test cases. >> Thanks, >> Honnappa >> >> On 21 June 2017 at 11:38, Honnappa Nagarahalli >> <[email protected]> wrote: >>> Hi, >>> I think there is a need to identify tools and specific versions of >>> the tools from patch acceptance perspective. Any failures outside of >>> these versions should be the responsibility of the person facing the >>> issues, they should submit a patch for those versions and tools. >>> >>> Travis CI is a step in that direction. But I think we still allow >>> submissions of patches via email. So, for this case, should we >>> standardize the tools and versions being used in Travis CI as the >>> acceptance criteria? >>> >>> Thanks, >>> Honnappa
