Re: [Xen-devel] [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.05.19 at 17:54, <lars.kurth@xxxxxxxxxx> wrote:

> 
> On 16/05/2019, 04:47, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>     >>> On 16.05.19 at 00:18, <lars.kurth@xxxxxxxxxx> wrote:
>     > +# Mappings to track files are of the following format
>     > +# ---------------------------------------------------
>     > +# manual|auto xen-file name-of-original-repo original-file commit-id
>     > +#
>     > +# auto:
>     > +#   The xen-file needs to track the the original-file exactly
>     > +#   In other words, we can automatically update the file using a script
>     
>     Do we have _any_ example of this? I can't even imagine one, due
>     to e.g. our includes all starting with xen/ whereas Linux'es (just to
>     take as example) all start with linux/. Perhaps "auto" needs to
>     include sed expressions that need to be applied before actually
>     applying the original change to our tree?
> 
> I am not sure I fully understand your concern. 
> This was intended for the case where say we would exactly track 
> xen/.../foo.bar with linux/.../foo.bar
> In other words, auto only applies to the content of a file: the filename 
> isn't relevant, because all the information that would be needed to do this 
> is in the file.

When talking about file names in my reply, I referred to C language
#include directives inside the file in question, as a (pretty important)
example. There was no talk about the cloned/copied file's name itself.
Hence the suggestion to accompany auto: with a set of sed
expressions, which could then e.g. transform #include <linux/...>
into #include <xen/...>.

> @Julien, @Stefano, @Jan: are any of the files you listed fall into the 
> "should be tracked exactly" category?

As I've said before - I can't even imagine such a file to exist.

>     > +# manual:
>     > +#   A developer needs to make a decision whether a
>     > +#   specific change is applied or ignored and update the last commit id
>     > +#   accordingly
>     > +#
>     > +# name-of-original-repo:
>     > +#   A reference to a source repository defined by *repo* keyword
>     > +#
>     > +# commit id:
>     > +#   Last commit id of source file that was deemed to be ok
>     > +#   and either imported into the tree or rejected
>     > +#
>     > +# For example:
>     > +#   manual xen/drivers/passthrough/arm/smmu.c linux-torvalds 
> linux/drivers/iommu/arm-smmu.c b77cf11f094136
>     > +
>     > +version 1
>     
>     Perhaps it wouldn't hurt to include the colons in the actual entries as
>     well? 
> 
> I am not sure what you mean, which colons? Are you saying, the format should 
> be
> version: 1
> repo: ...

Yes. This would make it even more prominent that these are tags of
some sort. But this was only a thought of mine, it's in no way meant
to be a requirement I have.

> I think the confusion comes because I used colons after statements in the 
> comments. 

Right, that's how I got there.

> I think that "version: 1" is slightly more human-readable, so I would be OK 
> with that

A well defined non-blank separator also allows machine processing
to notice more easily if there's a malformed line. Plus (if need be)
it would permit tags with blanks in their names.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel