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