Why is it Hard? It is a matter of documenting/advertising which versions we are using in CI and making that as a minimum standard. If someone has a different compiler they can always submit the patches for their compilers.
On 21 June 2017 at 14:49, Maxim Uvarov <maxim.uva...@linaro.org> wrote: > it's very hard to standardize tools and compiler version. For now to > validate patches we use Linaro CI (odp-check scripts) and Travis CI > which is based on some stable ubuntu version. Also we really want > that all people can download odp, compile it and run. It's very rare > case if different tools introduce issues but some times it happen. > If such issue is found before patch submission it has to be fixed before. > > Maxim. > > On 06/21/17 22:19, Bill Fischofer wrote: >> On Wed, Jun 21, 2017 at 1:30 PM, Honnappa Nagarahalli >> <honnappa.nagaraha...@linaro.org> wrote: >>> On 21 June 2017 at 12:23, Bill Fischofer <bill.fischo...@linaro.org> 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. >> >> That's what we're trying to do with CI and Travis. In this specific >> case Petri discovered an issue that effected an older LTS level of >> Ubuntu and provided a simple fix to the issue. So I don't see a >> problem with propagating that fix as Brian seems to have confirmed >> that the fix is good. >> >>> >>>> >>>> On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli >>>> <honnappa.nagaraha...@linaro.org> 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 >>>>> <honnappa.nagaraha...@linaro.org> 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 >
