On the need to move to a merge request workflow

[Pavel Hrdina]

On Tue, Mar 17, 2020 at 10:01:24AM +0100, Peter Krempa wrote:
> 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.

Let me quote the paragraph in question:

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

If I understand it correctly there is no plan to kill libvir-list.
I completely support your concern about collaboration with QEMU
developers but I don't thing this move will affect that in any way.

Yes, existing core developers would probably have to watch two places
for libvirt development and yes new core developers would have to
subscribe to libvir-list as well if they need to cooperate with QEMU,
but I don't thing the real impact on existing core developers is that
significant.

If we move to GitLab I guess that most of us will configure email based
notifications for new pull requests or issues and since it's an email
you can do whatever you like with it, for example filter it into the
same folder as libvir-list.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200317/5bb8aa13/attachment-0001.sig>