Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 15 Aug 2019, at 16:58, Julien Grall <julien.grall@xxxxxxx> wrote:
> 
> Hi Lars,
> 
> On 15/08/2019 16:46, Lars Kurth wrote:
>>> On 15 Aug 2019, at 16:33, Lars Kurth <lars.kurth.xen@xxxxxxxxx 
>>> <mailto:lars.kurth.xen@xxxxxxxxx>> wrote:
>>> 
>>> 
>>> 
>>>> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel <wipawel@xxxxxxxxx 
>>>> <mailto:wipawel@xxxxxxxxx>> wrote:
>>>> 
>>>> Hi Lars, Julien,
>>>> 
>>>> Thanks for the pointers, I will read them up and follow the 
>>>> recommendations with my future contributions.
>>>> Sorry for the mess…
>>> 
>>> It's not really a mess: it must have been quite a pain to put the mails 
>>> together manually
>>> And it would become more painful for a second revision
>>> I have been through this myself
>>> 
>>>> But, let me ask first before reading the wikis, how do you prefer 
>>>> submitting series that contain patches belonging to 2 distinct repos (e.g. 
>>>> xen and livepatch-build-tools)?
>>> 
>>> That's a good question and a very rare use-case. We split them, as all the 
>>> tools such as git format-patch only work on one repo
>>> Applying patches also only works on a per repo basis
>>> 
>>> So, I would send two series. But mention the relationship in the cover 
>>> letter (and/or patch if it is a single one)
>>> 
>>> The tools in the docs currently may not work on livepatch-build-tools.git
>>> * First: there is no MAINTAINERS file in livepatch-build-tools.git, which 
>>> really should be added
>>> * Second: using xen.git:/scripts/add_maintainers.pl may not work when 
>>> called from within livepatch-build-tools.git
>>> 
>>> I am going to play with this and update the docs and if needed the tools 
>>> accordingly
>>> You may have to improvise in the meantime:
>>> * Step 1 & 3 will work: Step 2, option 1 will probably not (which means 
>>> until I have done this, you may have to follow option 2 and make sure that 
>>> the right people are CC'ed)
>> I can confirm that Step 2 does not work without some tools changes to 
>> scripts/add_maintainers.pl when called from within a non-xen.git repo
>> And
>> git send-email --to xen-devel@xxxxxxxxxxxxxxxxxxxx 
>> <mailto:xen-devel@xxxxxxxxxxxxxxxxxxxx> 
>> --cc-cmd="../xen.git/scripts/get_maintainer.pl" --dry-run -1
>> errors with
>> ../xen.git/scripts/get_maintainer.pl: The current directory does not appear 
>> to be a Xen source tree.
>> I need to fix this. Hopefully get_maintainer.pl isn't too dependant on the 
>> actual Xen tree
> 
> get_maintainer.pl relies on the current working directory to be the top of 
> tree.
> 
> At the moment, it checks various file are present (see top_of_tree) but I 
> think it should be feasible to just relax it to just MAINTAINERS.
> 
> The risk is a user may end up to call the wrong MAINTAINERS file if it messes 
> up the current working directory (i.e calling for Xen patches from 
> livepatch-tools). Not sure if this is a real concern though...
> 
> Note that Linux has a similar check to ensure the user is on the right 
> directory (i.e

I know, that's where we inherited that from. I suppose the issue is that the 
MAINTAINERS file format may be different in another tree and thus the tool may 
fall over.

In any case: I have a patch which prints out a warning rather than abort

I will send once I made corresponding change to get_maintainers.pl, which seems 
to have call locations to add_maintainers.pl hardcoded in it

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