Re: [libvirt] [PATCH 0/3] qemu: Drop some cruft

On 09/12/2018 06:24 PM, Ján Tomko wrote: right, my fingers not typing what I'm thinking, mea culpa. I don't see them as too hard to follow. In fact they're pretty simple as long as you have seen the code. I saw no need to request a repost unless it was because of the .replies differences. The hardest part is the move of the code from domain_conf to qemu_domain and since I requested and made those changes, I can see 'reason' to assist with adjusting the patches I was reviewing. Managing the capabilities conflict was less trivial and I certainly don't remember all the names of the various tools that were created that are supposed to help in the endeavor. 1. It's not orderly. Review of upstream series is "ad-hoc" at best. Some series get immediate review, ack, and push. Sometimes certain series languish for no apparent reason. When those series contain capabilities changes it can quickly creates conflict. 2. At certain times there seems to be a "run" or "rush" to make capabilities changes based on priorities perhaps not related to upstream that create conflicts for patches that are languishing. 3. I think if we agree something is "good to add" capability wise and even though all the code isn't ready, the capability changes could go forward while perhaps the resolution of all review comments is handled. Yes, it's more of a problem when .replies changes. OK sometimes trivial to resolve... If one can keep up to date with changes or 'git am' doesn't have conflicts trying to apply changes. One has to go back in time with git checkout to a series before the update that caused the conflict, git apply patches, then --set-upstream-to=origin/master, and then git pull --rebase. And then you get to try to use any of the tools to help resolve conflicts - if you know about them and if they work; otherwise, it's a hand-edit or request to repost. Unless you know of some other neat trick or two... How would qemucapsfixreplies fix the environment where git am fails to do the merge. I didn't recall the name when processing the .replies files. I'm also not sure having taken a quick peak at the code whether it would have helped since there was "conflict" as a result of 4 replies being removed and 1 reply being added in a very similar spot in the file. As noted in the review - whenever I've created .replies files from scratch using the tools - something in my process doesn't create output in the exact format some seem to expect, so I've given up creating them and just wait for someone else to do it. True... These were, but considering they were reviewed 16 minutes after posting and the previous series was reviewed similarly as quick and those caused merge conflict issues - I reacted to just the fact that capabilities changes were taking place and asked to consider the "orderly processing" of posted patches. I didn't dig into them because I was in the middle of something else. John