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

[George Dunlap <George.Dunlap@citrix.com>]

> On Jun 22, 2018, at 4:11 PM, Julien Grall <julien.grall@arm.com> wrote:
> 
> Hi,
> 
> On 06/22/2018 08:42 AM, Jan Beulich wrote:
>>>>> On 22.06.18 at 00:24, <dougtrav@icloud.com> 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.

 -George


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