Re: thoughts on a Merge Request based development workflow

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Neil,

On Tue, Sep 24, 2019 at 02:53:12PM -0400, Neil Horman wrote:
> On Tue, Sep 24, 2019 at 02:37:28PM -0400, Drew DeVault wrote:
> > On Tue Sep 24, 2019 at 2:25 PM Neil Horman wrote:
> > > 	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.
> > 
> > This is a great idea.
> > 
> > > 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.
> > 
> > Until this part. Phasing out email in favor of a centralized solution
> > like Gitlab would be a stark regression.
>
> Well, that by no rights has to happen (at least not in my mind).  I wouldn't
> have an issue with maintaining a mailing list in perpituity.  I only mean to say
> that if common practice becomes to us the git interface to preform reviews, and
> email usage becomes less needed, a given project could choose to phase it out.

My opinion on this is that if anyone wants to move towards a more
git-centric workflow, be it for review, pull/merge requests, or anything
else, we will have to figure out a way to make this decentralised and
not bound to a single server instance. Without interoperability between
servers and decentralisation, the result will be vendor lock-in, and
that's a no-go for a large part of the community.

How this could be achieved remains to be discussed, and should be an
interesting exercise.

-- 
Regards,

Laurent Pinchart