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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 17/05/2019, 01:34, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

    >>> 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/...>.

That makes perfect sense now. In that case, I tend to agree that "auto" is 
probably not needed. Would be quite happy to drop it.
    
    > @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.
    
I can do that. No problem.

Any other comments from anyone, before sending version 2?

Lars    
    

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