Re: thoughts on a Merge Request based development workflow

[David Rientjes <rientjes@google.com>]

On Tue, 24 Sep 2019, Neil Horman wrote:

> Hey all-
> 	After hearing at LPC that that there was a group investigating moving
> some upstream development to a less email-centric workfow, I wanted to share
> this with the group:
> 
> https://gitlab.com/nhorman/git-lab-porcelain
> 
> Its still very rough, and is focused on working with RH based workflows
> currently, but it can pretty easily be adapted to generic projects, if theres
> interest, as well as to other services besides gitlab (github/etc).
> 
> The principle is pretty straightforward (at least currently), its a git
> porcelain that wraps up the notion of creating a merge request with sending
> patch emails.  It uses the gitlab rest api to fork projects, and manipulate MR's
> in sync with email patch posting.  It also contains an email listener daemon to
> monitor reqisite lists for ACK/NACK responses which can then be translated into
> MR metadata for true MR approvals/notifications to the maintainer that a branch
> is good to merge.
> 
> Ostensibly, if this has any sort of legs, the idea in the long term is to add
> the ability to use the porcelain to do reviews on the command line, and
> eventually phase out email entirely, but I think thats a significant way off
> here.
> 
> Anywho, food for thought.
> 

This is very interesting.

It may be off-topic but this email raised my curiosity about how features 
are maintained internally before they are ready to propose to upstream, 
especially when those features are developed over multiple upstream base 
releases.

We have features that we maintain in-house until they are ready to push 
upstream and while they are still under active development or we are 
collecting data to use as motivation for asking that feature to be merged.

For this, we have historically always rebased these features on top of new 
kernel releases (unfortunately not 4.20 -> 5.0 -> 5.1, but somewhere in 
between like 4.20 -> 5.2) and that creates a lot of churn, developer 
resources, and rewrites the git history.

Exploring options for maintaining these features by merging rather than 
rebasing has been done: instead of rebasing from 4.20 to 5.2, for example, 
as a clean series on top of 5.2, we fork the feature branch based on 4.20 
off and merge it with 5.2, fix it up, run tests, and publish.  The thought 
process here was that we can always git rebase --onto linus to create a 
nice clean patch series for posting upstream or asking for a git pull from 
upstream.

I'd be very interested to know how others maintain patch series across 
multiple base kernel version especially when they need to maintain the 
feature for those kernel versions separately, how RH handles their patches 
before they are ready to be officially posted, etc.