Re: On the need to move to a merge request workflow

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.

Based on what I see with other projects, they generally encourage design discussions to happen in the issue tracker. The designs may lead to many distinct pieces of work, each of which get turned into todo items and associated with separate merge requests. So the issue tracker is basically used to discuss / plan / coordinate all the non-coding work. With this approach there's not really much compelling reason to keep using the libvir-list. If you look at systemd, after they moved to merge requests, their mailing list still exists, but it mostly just has end user questions. For libvirt this role is filled by the libvirt-users mailing list. I wouldn't shut down libvir-list, but I wouldn't expect significant traffic in the long term.