[dpdk-dev] [PATCH 1/2] examples/tep_term: fix offload on VXLAN failure

[Yuanhan Liu]

On Mon, Sep 12, 2016 at 11:36:01AM +0200, Thomas Monjalon wrote:
> 2016-09-12 08:42, Tan, Jianfeng:
> > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> > > FYI, my testrobot caught some errors when this patch is applied.
> > 
> > It's because this patch set has dependency on a previous patch set, which seems a difficult scenario to handle. There's no standard to state the dependency, right?
> 
> No there is no standard to state the dependency.

Yes.

> We need one.

We could.

> Actually, there are 3 kinds of dependencies:
> 	- a well know dependency when sending a patch

Not quite sure what it is.

> 	- implicit dependency on the HEAD

If the HEAD is in one of the DPDK public three (no matter which it is),
no issue. My robot will try to apply a patchset to all available trees,
one by one, until it succeeds.

If the HEAD is a local commit (say, like this case, you made a patch
based on some patches from community that haven't been applied yet),
it's hard. The only way we can do is that we can do some brute force
to get the right combination if no hint given. But I think of no reason
to do that: it just brings complexity. So, we could either ask a hint
from the author (the tag you mentioned below, or provide a git tree
(the alternative I'd suggest, details go below).

> 	(can fail if a conflicting patch is pushed)

It also can be fixed quite easily: when failed, it could go few commits
backwards, until a right base is found.

> 	- dependency on a specific tree (next-*)

Not an issue, as stated above.

> 
> I suggest using:
> 	Depends-on: pw <patchwork-id-of-the-patch>|<tree> <hash>
> Examples:
> 	Depends-on: pw 33000

This one is necessary, both for an auto tools and for some people to have
a try.

> 	Depends-on: master 3643b0f
> 	Depends-on: next-net f33e00

I see no good reason to do that, for that's typically where patches apply.
And since we have introduced sub-trees, it then should be obvious (for
frequent contributors) that if you are making a patch to a PMD driver,
you should grab the next-net tree and make patch there. Vice verse, if
you got a PMD patch from mailing list and want to have a try, you should
try to apply it to the next-net tree. Well, it may fail because the patch
author doesn't know this generic rule, that he made patches based on master,
you then could have a try with master.

Besides, it just adds extra burden to developers: think that we have to
add such tag to every patch.

> 
> It won't work well when a patch depends on a pending patch series
> because the cover letter has no patchwork identifier.
> It will be solved with the next version of patchwork (in few months).
> In the meantime, we can point to the first patch of the series.
> 
> Comments/ideas?

The alternative I'd suggest is to use git trees. I'm going to add the
support of git-tree-based test (hopefully, I could do that this weekend).

I'd suggest all frequent contributors to have its own DPDK tree (publicly,
say at github, or internally, only works for intel). Every one has a local
git, what you need to do is to push your local git to a remote tree. You
then tell me the tree URL, my robot will fetch your tree timely. Once you
have pushed something, it will start the build test. You could even get a
report when it finishes, if you wish.

In such case, there is no dependency at all: because the developer already
fixed that if any.

As stated, it's an alternative. People could choose the one they prefer.

	--yliu