On Wed, May 27, 2020 at 10:51:21 +0200, Aleksandar Markovic wrote: > уто, 26. мај 2020. у 15:04 Aleksandar Markovic > <aleksandar.qemu.devel@xxxxxxxxx> је написао/ла: > > > > уто, 26. мај 2020. у 14:50 Peter Krempa <pkrempa@xxxxxxxxxx> је написао/ла: > > > > > > On Tue, May 26, 2020 at 14:37:41 +0200, Aleksandar Markovic wrote: > > > > > > > > > > > > +mips ``fulong2e`` machine (since 5.1) > > > > > > +''''''''''''''''''''''''''''''''''''' > > > > > > + > > > > > > +This machine has been renamed ``fuloong2e``. > > > > > > + > > > > > > > > > > Libvirt doesn't have any special handling for this machine so this > > > > > shouldn't impact us. > > > > > > > > > > > > > Well, Peter, > > > > > > > > I was also wondering libvirt listed as a recipient, and I think it > > > > creates unneeded noise in your group, but Philippe uses some his > > > > system for automatic picking of recipients, and libivrt somehow > > > > appears there during that process. Philippe, either correct that > > > > detail in this particular component of your workflow, or change > > > > entirely your system for recipient choice - the current workflow > > > > creates incredible amount of noise, wasting time of many people. > > > > > > Note that my message above was not a criticism of why we've got it but > > > more of a review. This review though it just that removing this is okay > > > and no action needs to be taken. Unfortunately I'm usually not familiar > > > enough with qemu to do a full review. > > > > > > > > > > > This happened before in case of deprecating an ancient mips machine, > > > > that absolutely doesn't have anything to do with linvirt. > > > > > > In some cases it might seem like that. Specifically for things where > > > libvirt isn't impacted such as machine type change because we try to > > > stay machine type agnostic or for something that we don't use. > > > > > > On the other hand there were plenty cases where we were impacted and > > > where we do want to know about these deprecations. It's in fact the > > > primary reason why this was established after an agreement between qemu > > > and libvirt projects and in fact I was one of those who argued for > > > adding such a thing. > > > > > > As I was one of the proponents I feel obliged to always respond to these > > > notifications as we've more than once encountered something that in the > > > end impacted libvirt. > > > > > But, Peter Krempa, > > I see libvirt-dev listed as a recipient for a patch (from this series) > that changes an e-mail of a colleague of mine. Why would be Currently the tooling creates a union of recipients based on the set of files changed by the patchset and then sends the whole series to everybody. That is to ensure that the recipient has the full context. > libvirt-dev be interested in that? Is libvirt really so sensitive to > the degree that to be afraid that changing an e-mail of a QEMU > contributor would impact libvirt design and/or its interface towards No, we don't care about that. We care about changes to the 'docs/system/deprecated.rst'. In this very specific instance we usually don't even care about the context of the other patches and can look them up manually if necessary. The problem is that the tooling currently doesn't really allow this usage. The next best thing is to send more emails rather than forget to send the notification. > QEMU? If you wishes that to remain so, I am of course fine with it, > who am I to determine that, but it looks like a severe overkill to me. Feel free to fix the git-publish tool. IMO asking maintainers/contributors to just CC patches which change 'docs/system/deprecated.rst' to libvirt-list would create too complicated rules and is in general not worth doing. Just if we can do it programatically. If this ever becomes a problem for libvir-list I'm sure that we'll drop ourselves from the CC if we reach such consensus. Please don't question this approach any more if you don't plan to fix the tooling.
