On the need to move to a merge request workflow

Daniel P. Berrangé berrange at redhat.com
Fri Mar 6 12:48:32 UTC 2020


On Fri, Mar 06, 2020 at 01:35:48PM +0100, Peter Krempa wrote:
> On Fri, Mar 06, 2020 at 11:44:07 +0000, Daniel Berrange wrote:
> 
> [...]
> 
> Many of the things outlined below can be also read as "if you spend some
> effort in using the proper tools and using proper approaches" you can be
> more effective than the web-tools which are better than the default
> approach but far from great. Arguably you could apply same logic on the
> web based workflow too, but we are in a gravity well of having stuff set
> up to our liking.

That is certainly a valid interpretation of some of the points. I think
it applies more to long term contributors than to infrequent contributors.
IOW, if you are a long term contributors you'll always benefit from
investing time to optimize your work no matter what the tools. If you
are an infrequent contributor the need to invest time to use the tools
not a good tradeoff, especially if that's project-specific  knowledge.
Any of course that assumes it is even possible to use the tools in the
first place, which we've seen is not the case for email, with contributors
suffering lost mail. 

> I also presume the 'merge request' workflow still supports doing
> fast-forward merges only as that would be a very big regression since
> we've kept linear history until now.

Yes, both fast forward only, and merge commits are available as options.
We'd obviously choose fast forward as our initial default.

There is a third option, which is a hybrid of the two - merge commits
with semi-linear history. This requires the code to be a fast-forward
commit, but then creates a merge commit anyway. So you still effectively
have linear history.  The potential benefit of this is that the merge
commit has a commit message that is machine generated that can include
a link back to the merge request that triggered it - IOW an audit log
of merges. This might make it appealing to use, but I've never tried
it out, so can't say much more on pros/cons of it.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list