On the need to move to a merge request workflow

Peter Krempa pkrempa at redhat.com
Tue Mar 17 09:01:24 UTC 2020


On Tue, Mar 17, 2020 at 09:42:30 +0100, Michal Privoznik wrote:
> 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:

[...]

> >> 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.

See the second paragraph of another subthread of this discussion:

https://www.redhat.com/archives/libvir-list/2020-March/msg00196.html

I wanted to raise this issue separately so that it's not burried. At any
rate, the idea of switching to the forge is to stop using email.

While this might appeal to upper layer developers where the cool new
deveopment approaches are used, we should not jeopardize our
relationship with qemu as we are trying to offer them our value
especially in the region of deprecation and changes of interfaces which
we are making transparent to users.

And if we are not going to kill off the libvir-list, the wins described
in the original thread are not as clear cut, as it just adds things you
have to watch/deal with, but for any real work, you'll have to endure
the pain from both email and web-based forges.




More information about the libvir-list mailing list