On Tue, Mar 17, 2020 at 09:47:22 +0000, Daniel Berrange wrote: > On Tue, Mar 17, 2020 at 09:26:44AM +0100, Peter Krempa wrote: > > On Tue, Mar 17, 2020 at 09:20:07 +0100, Michal Privoznik wrote: > > > On 17. 3. 2020 8:52, Peter Krempa wrote: > > > > On Fri, Mar 06, 2020 at 11:44:07 +0000, Daniel Berrange wrote: > > > >> We've discussed the idea of replacing our mailing list review workflow with > > > >> a merge request workflow in various places, over the last 6 months or so, > > > >> but never made a concrete decision. > > > > > > > > One other thing that worries me about this is that we've finally > > > > established a way close to qemu developers for notifying us if they are > > > > going to deprecate something or change something important. > > > > > > > > With moving development to some random web page with non-standard > > > > interfaces this will just mean that the notifications in this process > > > > will either stay on the old mailing list or be forgotten if we don't act > > > > on them. > > > > > > > > Moving development to some other place will in this regard just mean > > > > that we'll have to watch two places at the same time. > > > > > > > > While this seems to be a very low impact thing, the advantages of the > > > > new process you've outlined will only ever apply to drive-by > > > > contributors. Anybody wanting to take it seriously will necessarily need > > > > to subscribe to the mailing list anyways. > > > > > > > > In the end I just don't want to destroy the relationship with qemu > > > > developers by not acting on the notifications of change they send to us. > > > > > > > > > > > > > > I don't think I share this view. The way qemu developers notify us is > > > cross-posting to libvir-list. They can still do that and with the > > > traffic on the list going down it will be pretty easy to spot these > > > cross posts. Or am I missing something? > > > > Yes. As mentioned above though you need to be subscribed to the list > > though. Also as mentioned above, that means that any serious developer > > will need to be subscribe to the list. So all the point of not having to > > subscribe to the list applies only to drive-by contributors. > > Our long term contributors are the only ones who are likely to take any > actions based on the QEMU cross-posted messages, so I don't think we'll > loose anything measurable in this regard. Sounds a bit hypocritical then. The merge request workflow is inconveniencing long term contributors so that we can attract new contributors. If the new contributors aren't seeing those they won't be able to act on them. And if we don't expect new contributors to be involved to that extent, why are we even doing this? > We could probably do with formalizing our handling of QEMU deprecations > too. There have been a couple of occassions where we saw the message buta I think that requiring qemu developers to sign up to some web-page to file something are going to be detremental to the effort. The notifications are based mostly on the fact that changes to the file documenting the deprecations are automatically CCd to libvirt-list. This way if a drive-by qemu contributor sends patches they might not care enough to go through the notification process in the first place. > then failed to take action. It might be worth us explicitly filing an > issue against libvirt for every deprecation warning, so that we know > what is outtstanding on our todo list in this regard. There are also instances, where we've seen the message, filed bugs (issues) and not taken action. It's always human factor. There are at least these that I know of and there wasn't any action taken: https://bugzilla.redhat.com/show_bug.cgi?id=1783355 https://bugzilla.redhat.com/show_bug.cgi?id=1717899 I didn't even bother looking into the upstream bugzilla btw. There's a giant pile of stuff which was filed but nobody cares about. I'm not sure if we want to mirror that to whatever-hub/lab but either way given some time I feel it will end up the same way as the upstream bugzilla.
