Re: On the need to move to a merge request workflow

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.

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

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.