On Wed, Sep 12, 2018 at 09:45:32AM -0400, John Ferlan wrote:
On 09/12/2018 09:35 AM, Andrea Bolognani wrote:
> On Wed, 2018-09-12 at 09:09 -0400, John Ferlan wrote:
>> Any chance this can wait? Would be nice to have other series posted
>> upstream that have changes to .xml and .replies files to add new
>> functionality be processed first.
>>
>> There's a series to use - memfd from Marc-Andre Laurent that gets impacted.
* Lureau
>
> I see you've already had to rebase locally to apply the patches at
> all, due to other changes being pushed in the meantime, so I don't
> see how pushing this series too would make it any worse.
>
> Also IIUC you've asked Marc-André to make some changes that depend
> on *another series* of yours, that still hasn't been pushed, which
> means a respin will be necessary either way, won't it?
>
> All in all I see no reason to dealy pushing this.
>
OK - go ahead. It was just a "would be nice" type inquiry.
I don't see how that negates the need to post another version,
because the intermediate diffs got too hard to follow.
It's not the
first time capability changes cause conflicts and it won't be the last
unless we come up with a better process for them.
What's wrong with the current process?
The capabilities conflicts are trivial to resolve and we have automated
tools for most of it (VIR_TEST_REGENRATE_OUTPUT, group-qemu-caps.pl,
qemucapsfixreplies)
Also, Andrea's series seems to be innocent in this - the removed
capabilities do not alter .replies and the .[ch] file changes are
contained to the middle of the capabilities array, so they should
be resolved trivially by git.
Jano