Yes we can document that. 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. 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 > >> >
