Re: [dpdk-dev] [dpdk-ci] [PATCHv3 0/4] dpdk: enhance EXPERIMENTAL api tagging

[Thomas Monjalon <thomas@monjalon.net>]

09/01/2018 02:32, Neil Horman:
> On Fri, Jan 05, 2018 at 11:00:52AM -0500, Neil Horman wrote:
> > On Fri, Jan 05, 2018 at 03:08:52PM +0100, Thomas Monjalon wrote:
> > > 04/01/2018 13:56, Neil Horman:
> > > > On Sat, Dec 30, 2017 at 12:15:17PM -0500, Neil Horman wrote:
> > > > > Thomas-
> > > > >      I just noticed that the ci tests are failing on the intel compiler, which
> > > > > makes very little sense to me, as the error is a permission error on a bash
> > > > > script that added in this series, which works during the gcc compilation.  Can
> > > > > you take a look at that please?
> > > > > 
> > > > > thanks
> > > > > Neil
> > > > > 
> > > > Ping again Thomas, I've still heard nothing from you or the CI group about
> > > > getting more visibility into the odd permission problem in the CI runs this
> > > > seems to be encountering.  I'd love to fix it, but the information in the report
> > > > is insufficient to have any idea whats going on and the problem does not occur
> > > > on local builds.  Please advise.
> > > 
> > > Unfortunately, I have no clues about this setup.
> > > The report is sent by sys_stv@intel.com.
> > > Adding Qian as Cc.
> > > 
> > > The error is "buildtools/experimentalsyms.sh: Permission denied"
> > > And the file mode is 100755.
> > > 
> > > Anyone from Intel to check what happens please?
> > > 
> > Thank you Thomas.  I would really like to get this pushed in, as others have
> > acked it, but the lack of visibility into the CI errors is quite frustrating
> > Neil
> > 
> > 
> So I'm not sure where to go with this.  I've emailed the ci group on their list,
> I've asked them directly on this list, and asked you, Thomas for assistance in
> getting hold of the ci maintainers, and there has been no response in over a
> week now.  This patch has been acked by a few people, and the builds work on
> clang and gcc locally just fine.  I'm inclined to ask you to take these patches
> despite the ci errors.  If the CI maintainers can't respond to needs for
> visibility into the system, I don't think its reasonable to block patches based
> on CI results.
> 
> Thoughts?
> Neil

Yes, you're right, we can bypass this CI test.