[dpdk-ci] Master compilation failures in Intel CI

David Marchand david.marchand at redhat.com
Tue Jan 14 10:51:26 CET 2020


On Tue, Jan 14, 2020 at 9:04 AM Thomas Monjalon <thomas at monjalon.net> wrote:
>
> 14/01/2020 08:18, Chen, Zhaoyan:
> > - most of the patches in patchset are aimed to specific PMD driver,
> >    but just several patches for makefile/build script/config file(common files).. in patchset.
> >    (e.g. https://patchwork.dpdk.org/patch/64384/)
> >    This kind of patchset will be pointed to dpdk master

The problem with this patch is that it changes the MAINTAINERS file itself.
The "guess" script works on the origin/master version of the file, not
after the patch is applied.
So the script will point at dpdk master anyway for the patch you
mentioned, since drivers/common are currently going through master.

I'd say those situations are rare and we must look carefully to set
the subtree when adding a new component.

>
> We should filter out config/, mk/ and MAINTAINERS in the decision.

I prepared a change for this.

>
>
> > - one patchset includes document change and other specific PMD driver change.
> >   This kind of patchset will be pointed to dpdk master
>
> For doc/, we must make sure each part of the doc is well sorted
> in MAINTAINERS so we can distinguish crypto and ethdev docs for instance.

The doc/ pattern is currently filtered out, if this is what you are
referring to.


> > For these 2 situations, basically, next-* branches are ahead of master,
> > developers expected their patches could be tested on next-*, since that is code base under developing.
> >
> > So applying these kinds of patchsets to next-* are more meaningful for them.
>
> I agree.

I sent an update on MAINTAINERS, and I am about to send the change
that filters mk/, config/ and MAINTAINERS.

Can you give me a list of patchsets you think are problematic so that
I can test them?
Thanks.


-- 
David Marchand



More information about the ci mailing list