Ah, I get it now -- there's only 1 Travis; it's a hosted service. I missed that point before. :-)
For usNIC, we just need libnl (including .h files) or libnl3; either one is fine. > On Oct 12, 2015, at 3:26 PM, Jeff Squyres (jsquyres) <[email protected]> > wrote: > > On Oct 12, 2015, at 2:50 PM, Hefty, Sean <[email protected]> wrote: >> >>> I'm not sure I understand the distinction...? >> >> I'm referring to a script that is *stored in the upstream github tree*. >> This is an 'ofiwg' script, not a vendor script. Today that builds the >> sockets provider and runs all fabtests against it. > > OIC. > >> We won't be able to run the other providers, but we should be able to build >> them. > > Well, maybe. > > Are you saying that everyone who does the CI testing has to use the upstream > Travis config? I don't think we want to do that. > > E.g., I don't anticipate downloading and installing PSM, PSM2, uGNI, ...etc. > dependent libraries. I'll test what I can easily test, and add that to the > union of what other people are testing. I.e., as a *project* we want to > ensure that all of those providers can compile and install, but you don't > necessarily need to require that *everyone* compile/install *all* providers. > You only care that the union of all testing covers all providers. > > I think the best bet would be to define a baseline of what you want people to > test as part of the github CI stuff. E.g., run the fabtests. If they run > exactly those guidelines, great. If they do more than that, that's also > great. > > For example, my tests will likely be some variation of running the fabtests, > plus perhaps a few other minor sanity checks to ensure that usnic is working > properly. > >> The question is what policy to use in selecting the external libraries. >> That's the input I'm looking for, rather than just picking some policy on my >> own. > > I still think that this is a decision best left to the individual testing > sites. > > I.e., I don't know if that travis.yml file will be suitable for everyone > without any local editing for their local setup. > >> Why does this matter? It matters because this is run as soon as the pull >> *request* is opened. If the test fails, the PR is flagged with the failure. >> Github allows us to prevent merging PRs which have failed the pre-merge >> checks. Today they are only flagged. > > I saw that Github recently added this, too. Based on our experience at the > Open MPI github, false positives happen more than you would hope/like. :-\ > I.e., a Jenkins goes wonky at some particular site for whatever reason -- > either the test incorrectly fails, or someone accidentally changed something > at that testing site, or ...one of a hundred other reasons. > > My $0.02 would be to not enable that new Github feature until you can get > some confidence in everyone's CI testing. > > -- > Jeff Squyres > [email protected] > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > -- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
