On the need to move to a merge request workflow

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


On 17. 3. 2020 9:26, 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.
> 

Sure, but I thought this is expected. Every project has a place to
discuss ideas, make decisions. Some use pull requests to do that (please
don't), some have a mailing list. I see libvirt in the latter group. And
to some extent, we are already in that situation. I mean, if I were a
drive by contributor, I would subscribe to the list, post my patches and
ignore the rest of incoming e-mails from the list.

Maybe I'm misunderstanding and what is suggested it to move even all the
discussion to gitlab. If that is the case, I stand by you. We should not
do that. But if we are moving just the repo then I guess it is fine.

Michal




More information about the libvir-list mailing list