Hi Lars,
On 18/09/2019 13:14, Lars Kurth wrote:
On 18/09/2019, 12:15, "Julien Grall" <julien.gr...@arm.com> wrote:
Hi Ian,
On 18/09/2019 11:41, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely identify
.rodata sections"):
>> On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
>>> $ scripts/./add_maintainers.pl -d ~/git/livepatch-build-tools
>>
>> '-d' only tells you where the patches files are. The script will look
up for the
>> MAINTAINERS file in the current directory.
>
> Hmmm. I wonder if we could detect this situation somehow. This will
> be a common user error I think.
I think it would be possible for patch modifying file. We could check
whether
the file modified exist in the repo. Though, I am not sure how difficult it
would be to implement.
That might be doable, but won't be easy as I will essentially need to parse the patch
And it won't be reliable.
The only workable way of doing this may be to have a strong convention
that requires to use the [REPONAME PATCH] via --subject-prefix when generating
the
patch and for add_maintainers.pl to verify this somehow based on the current
directory and the patches.
We already have strong conventions in some cases, e.g. for OSSTEST we always use
[OSSTEST PATCH]. This would potentially be helpful for the CI loop plans aso.
Assuming there is a git config setting for --subject-prefix then this could be
made
to work. I could add a section under [1] to document the convention with the
appropriate git command. We could include a script (e.g.
xen.git:scrips/git-setup)
which does this based on the repo name automatically.
I saw a conversation on IRC about this. But it is not clear if there was any
conclusion?
My only slight concern about tagging by default is the length of the subject,
when directly receiving from xen-devel (i.e. not CCed), the subject is already
[xen-devel][PATCH XX/XX]. I am assuming the tag will not be dropped so it will
appear on the mailing list. For repo such as LIVEPATCH-BUILD, this would end up
to lengthy prefix.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel