On the need to move to a merge request workflow

Michal Prívozník mprivozn at redhat.com
Tue Mar 17 08:20:07 UTC 2020


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?

Michal




More information about the libvir-list mailing list