[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