Re: thoughts on a Merge Request based development workflow

[Neil Horman <nhorman@tuxdriver.com>]

On Tue, Sep 24, 2019 at 04:15:18PM -0700, David Rientjes wrote:
> 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.
> 
As far as kernel features are concerned, RH follows an upstream first policy
(and does so generally speaking for all of our products).  If a new feature is
to be developed, we do so against the latest upstream, always, and then the
effort becomes one of adapting those features to the RHEL stabilized kernels.
That shifts the effort from constantly needing to adapt an existing feature to a
newer kernel, to needing to do take a newly developed feature and backport it to
an older stabilized kernel.  Its not necessecarily any less work per-se, but we
find it accelerates the development of the actual feature.

HTH
Neil