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

[Neil Horman <nhorman@tuxdriver.com>]

On Tue, Jan 09, 2018 at 10:20:05AM +0100, Thomas Monjalon wrote:
> 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.
> 
Thank you, much appreciated.
Neil