On 22 June 2017 at 02:18, Maxim Uvarov <maxim.uva...@linaro.org> wrote: > Yes we can document that. That would be greatly helpful, knowing exactly what are the check points.
If Travis passes patch can be send to mailing > list. We should continuously improve Travis scripts to add more build and > targets. We can add hooks to compile it and run on different hardware which > we care about. > Problem with Travis is that we do not control it. Images can be updated. > Virtual machines can be down and etc. > > To check different tools version we update DEPENDENCIES and ./configure > script. > > The other problem is that patch introduced some problem. Like it does not > compile on new version of Ubuntu. Yes it's hard to predict that but it has > to be fixed before merging if feedback was get on mailing list. This is the change in compilation environment. We as a community need to accept to introduce/upgrade to this new environment. Otherwise, if all of us have environments that differ, it becomes difficult for one contributor to satisfy all the environments. > > Best regards, > Maxim. > > > > On 22 June 2017 at 08:42, shally verma <shallyvermacav...@gmail.com> wrote: >> >> On Thu, Jun 22, 2017 at 3:03 AM, Honnappa Nagarahalli >> <honnappa.nagaraha...@linaro.org> wrote: >> > 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. >> > >> I second this opinion as I also had same question in last weekly public >> call. >> if using a travis CI a way to go then it will be helpful if could be >> documented as minimum acceptance criteria for patches with bit of >> pointers on how to use it to help novice user like me. >> >> Thanks >> Shally >> >> >> > 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 >> >> > >
