On the need to move to a merge request workflow

[Peter Krempa]

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.