Re: [Xen-devel] [PATCH] build: sync Kconfig with Linux v4.17

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Jun 25, 2018, at 11:13 AM, George Dunlap <George.Dunlap@xxxxxxxxxx> wrote:
> 
> 
> 
>> On Jun 22, 2018, at 4:11 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
>> 
>> Hi,
>> 
>> On 06/22/2018 08:42 AM, Jan Beulich wrote:
>>>>>> On 22.06.18 at 00:24, <dougtrav@xxxxxxxxxx> wrote:
>>>>>>>> Working patch by patch isn't feasible because of the renames.
>>>>>>> 
>>>>>>> I don't understand - how does path/file naming conflict with working
>>>>>>> patch by patch? Surely a relatively simple sed command could be used
>>>>>>> to change the paths in each patch according to our tree layout. That's
>>>>>>> basically what I'm doing with the MWAIT idle driver; granted, that's 
>>>>>>> just
>>>>>>> a single file.
>>>>>> 
>>>>>> Its 106 commits between the last time I got this in sync. We also don’t 
>>>>>> have
>>>>>> kbuild and we have a little shim file to map things to our build system 
>>>>>> so
>>>>>> for each patch I would have to implement some of those regressions.
>>>>> 
>>>>> Well, I still don't understand: You had to make those 106 commits apply
>>>>> to your tree as well in order to have create the patch you've submitted.
>>>>> Whatever you did (even if you created a giant patch first and massaged
>>>>> that one), the same could have been done for the individual commits. If
>>>>> this indeed takes more than a simple sed invocation, perhaps it would be
>>>>> worth adding a little script to our repo doing just that?
>>>> 
>>>> So I didn't take those 106 commits individually as it was indicated that
>>>> would have been NACKed.
>>> Interesting. Were there any reasons indicated why that would be?
>> 
>> I could see few reasons to be grumpy with such a series in my inbox. Sending 
>> a series with 106 is just insane, more that probably no-one is going to look 
>> at patches one by one (they are imported from Linux).
>> 
>> This is very similar to when a file is imported or update files from Linux 
>> (e.g usban, SMMU). We don't backport one by one the commit. Instead we batch 
>> in a single commit.
>> 
>> So why does it have to be different here?
> 
> It’s pretty common when sending series with huge patches (e.g., removal of an 
> entire subtree) to send the equivalent of a pull request, with a link to a 
> public git branch somewhere.  Perhaps we could adapt that method here?
> 
> After all, the diffstat should make it pretty clear that the changes limited 
> to the Kconfig code, which nobody cares much about except that it should 
> resemble Linux (primarily for compatibility reasons).
> 
> FTR I’m not opposed to a squashed patch, but there is an advantage to having 
> the individual patches, just in case we end up having to go back and figure 
> out how something ended up broken.

…but in any case, I think the Xen KConfig maintainer should have the final say 
here.

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