From: "Jan Beulich" <JBeulich@suse.com> To: Lars Kurth <lars.kurth@citrix.com> Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wei.liu2@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, george.dunlap@citrix.com, Julien Grall <julien.grall@arm.com>, committers@xenproject.org, xen-devel <xen-devel@lists.xenproject.org>, Ian Jackson <Ian.Jackson@citrix.com> Subject: Re: [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream Date: Fri, 17 May 2019 01:34:31 -0600 [thread overview] Message-ID: <5CDE6407020000780022FF63@prv1-mh.provo.novell.com> (raw) In-Reply-To: <530E0649-256F-4A11-B887-E665B3C92979@citrix.com> >>> On 16.05.19 at 17:54, <lars.kurth@citrix.com> wrote: > > On 16/05/2019, 04:47, "Jan Beulich" <JBeulich@suse.com> wrote: > > >>> On 16.05.19 at 00:18, <lars.kurth@citrix.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Jan Beulich" <JBeulich@suse.com> To: "Lars Kurth" <lars.kurth@citrix.com> Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wei.liu2@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, george.dunlap@citrix.com, Julien Grall <julien.grall@arm.com>, committers@xenproject.org, xen-devel <xen-devel@lists.xenproject.org>, Ian Jackson <Ian.Jackson@citrix.com> Subject: 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 Date: Fri, 17 May 2019 01:34:31 -0600 [thread overview] Message-ID: <5CDE6407020000780022FF63@prv1-mh.provo.novell.com> (raw) Message-ID: <20190517073431.VIza5RBOH0VEcLmrIiXVZjpQm6E3X_CZorTfRPgltJE@z> (raw) In-Reply-To: <530E0649-256F-4A11-B887-E665B3C92979@citrix.com> >>> On 16.05.19 at 17:54, <lars.kurth@citrix.com> wrote: > > On 16/05/2019, 04:47, "Jan Beulich" <JBeulich@suse.com> wrote: > > >>> On 16.05.19 at 00:18, <lars.kurth@citrix.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-05-17 7:34 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-15 22:18 [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 2019-05-15 22:18 ` [Xen-devel] " Lars Kurth 2019-05-16 10:46 ` Jan Beulich 2019-05-16 10:46 ` [Xen-devel] " Jan Beulich 2019-05-16 15:54 ` Lars Kurth 2019-05-16 15:54 ` [Xen-devel] " Lars Kurth 2019-05-17 7:34 ` Jan Beulich [this message] 2019-05-17 7:34 ` Jan Beulich 2019-05-20 16:05 ` Lars Kurth 2019-05-20 16:05 ` [Xen-devel] " Lars Kurth 2019-05-20 16:36 ` Ian Jackson 2019-05-20 16:36 ` [Xen-devel] " Ian Jackson 2019-05-20 16:59 ` Lars Kurth 2019-05-20 16:59 ` [Xen-devel] " Lars Kurth
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5CDE6407020000780022FF63@prv1-mh.provo.novell.com \ --to=jbeulich@suse.com \ --cc=Ian.Jackson@citrix.com \ --cc=andrew.cooper3@citrix.com \ --cc=committers@xenproject.org \ --cc=george.dunlap@citrix.com \ --cc=julien.grall@arm.com \ --cc=konrad.wilk@oracle.com \ --cc=lars.kurth@citrix.com \ --cc=sstabellini@kernel.org \ --cc=tim@xen.org \ --cc=wei.liu2@citrix.com \ --cc=xen-devel@lists.xenproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.