Re: thoughts on a Merge Request based development workflow

[Dmitry Vyukov <dvyukov@google.com>]

On Mon, Sep 30, 2019 at 3:01 AM Neil Horman <nhorman@tuxdriver.com> wrote:
>
> On Sun, Sep 29, 2019 at 02:55:25PM +0200, Dmitry Vyukov wrote:
> > On Sun, Sep 29, 2019 at 1:57 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > On Sat, Sep 28, 2019 at 06:58:48PM -0400, Steven Rostedt wrote:
> > > > On Wed, 25 Sep 2019 20:40:45 -0400
> > > > Neil Horman <nhorman@tuxdriver.com> wrote:
> > > >
> > > > > Eventually, barring any really significant objection, hes going to make
> > > > > the switch, and users will either have to get github accounts, or stop
> > > > > participating in netdev development.
> > > >
> > > > That will be a very sad day if that happened.
> > > >
> > > > Whatever service should have an email interface. For example, if I get
> > > > a message from bugzilla.kernel.org, I can reply back via email and it
> > > > is inserted into the tool (as I see my Out of office messages going
> > > > into it. I need to fix my scripts not to reply to bugzilla).
> > > >
> > > Forge solutions do have the ability to use email as an interface to
> > > issue tracking, thats not a problem.  What they don't currently seem to
> > > have is the ability to emulate patch review workflows.  And thats not to
> > > say they couldn't, but it seems to me that they haven't prioritized that
> > > because they offer several different types of comment options
> > > (commenting in the pull request discussion(s) themselves vs commenting
> > > on code, etc.  If they sould implement that, I think alot of this would
> > > become alot easier.
> > >
> > > > I set up patchwork on my INBOX, as I'm having a hard time of separating
> > > > patches from the noise. And it works really well. I would love to be
> > > > able to push my patchwork list to a public place so that others can see
> > > > it too. As mentioned in the Maintainers Summit, it would be great to be
> > > > able to pull patchwork down to my laptop, get on the plane, process a
> > > > bunch of patches while flying, and then when I land, I could push the
> > > > updates to the public server.
> > > >
> > > > That's pretty much all I'm looking for.
> > > >
> > > I think what you are looking for here is a way to pull down a set of
> > > merge requests, review and merge those you approve, and push them back
> > > when you are back online?  I think you can do at least some of that.
> > > Forge solutions (definately gitlab, likely github), allow you to pull
> > > a merge request reference namespace (on gitlab its
> > > heads/merge_requests/<merge_request_id>).  You can merge whatever head
> > > there you like to its intended target branch, and when you push, it will
> > > update the corresponding MR to the MERGED state.  What you can't
> > > currently do is make a comment on an MR, store that comment in git and
> > > then have the MR updated with those comments.  That would be a great
> > > item to make that feature more complete.
> >
> > One mismatch with kernel dev process that seem to be there for lots of
> > existing solutions (gerrit, git-appraise, github, gitlab) is that they
> > are centered around a single "mail" git tree (in particular,
> > gerrit/git-appraise check in metainfo right into that repo). Whereas
> > kernel has lots of kernels. Now if Steve is CCed on lots of changes
> > what git tree should he pull before boarding a place? For some changes
> > it may be unclear what tree they should go into initially, or that may
> > change over time. Then, there are some additional relations with
> > stable trees.
> > I suspect that kernel tooling should account for that and separate
> > changes layer from exact git trees. Like mailing lists. Usually there
> > is 1 mailing list and 1 git tree per subsystem, but still this
> > relation is not fixed and one can always CC another mailing list, or
> > retarget the change, etc.
> > What do you think?
> >
> I agree that newer review solutions (of the type you ennummerated) rely
> on centralization of information, which is undesireable in many cases,
> but I'm not sure how to avoid that.

Well, FWIW the SSB protocol and similar would avoid that:
https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains

> Just thinking off the top of my head, I wonder if a tool that converted
> all forge type conversations to git notes would be useful here.  Those
> could then be pulled by individuals for review and update?

git-appriaise does something similar, but the other way around:
https://github.com/dvyukov/kit/blob/master/doc/references.md#git-appraise
git notes is the _main_ storage, but then it has bridge to github.

However, it's unclear how use such solution for kernel:
https://lore.kernel.org/ksummit-discuss/9fee1356-cf48-6198-4001-5d9d886fbf88@iogearbox.net/T/#m869c5253d10931823bba74942df7da062a7bbb13
(world writable, force pushes)