From: Neil Horman <nhorman@tuxdriver.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Drew DeVault <sir@cmpwn.com>,
workflows@vger.kernel.org
Subject: Re: thoughts on a Merge Request based development workflow
Date: Thu, 26 Sep 2019 09:43:07 -0400 [thread overview]
Message-ID: <20190926134225.GA7235@hmswarspite.think-freely.org> (raw)
In-Reply-To: <CAMuHMdVbPFVLUBvQALR_fMbUpUWPpKKgdfkg5kY3v5nX42P_KA@mail.gmail.com>
On Thu, Sep 26, 2019 at 12:23:52PM +0200, Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Thu, Sep 26, 2019 at 11:58 AM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Tue, Sep 24, 2019 at 06:25:02PM -0400, Neil Horman wrote:
> > > On Tue, Sep 24, 2019 at 11:24:23PM +0300, Laurent Pinchart wrote:
> > > > 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.
> > >
> > > I think thats a bit of an overstatement.
> > >
> > > Yes, we definately want to avoid vendor lock in, and decentralization is
> > > definately a needed aspect of any highly parallelized workflow. That said:
> > >
> > > 1) Regarding vendor lock in, if you want to work with any workflow-as-a-service
> > > provider, your going to want tooling that talks to it (via the web ui, the
> > > command line, etc). But in the end, you're going to have to talk to that
> > > service. Thats all this tooling I presented does. And if you look at the REST
> > > apis for the major available services (gitlab/github), while they differ, their
> > > general objects and operations are sufficiently simmilar that they can be
> > > abstracted through tooling such that the same tool can be adapted to either.
> > > One would imagine that any to-be-created service would have sufficiently
> > > simmilar operations to also be adaptable to a generic set of operations
> >
> > Then let's create such a tool that also supports e-mail workflows, to
> > really offer a choice.
> >
> > > 2) Regarding decentrallization, the advantage of the decentrailzation of git
> > > lies in its ability for users to house their own local copies of a git tree, not
> > > so much in the ability to have multiple git servers (though the latter is
> > > important too). In either case, the use of gitlab or github doesn't enjoin you
> > > from doing that. You can still move your git tree around between clients and
> > > servers however you see fit.
> >
> > But it forces me to have one account with every git hosting service that
> > the projects I want to contribute to happen to select. Sure, we could
> > fix that by deciding to move the entire free software development to a
> > single git hosting provider, but that creates a vendor lock in issue
> > that few people would be comfortable with (including myself).
> >
> > > The thing to consider outside of that is the exportability of the data that
> > > resides outside of git - that is to say, if you want to move from gitlab to
> > > github, or from either to some 3rd service, or to a home built service, is there
> > > a way to export/import all that merge request and issue data, and honestly I
> > > don't know the answer to that, yet. I can see ways that it could be done, but
> > > am completely unsure as to how it should be done.
> >
> > There's one way, and we have it today, it's called e-mail :-) Jokes
> > aside, a bi-directional e-mail gateway would allow interoperability
> > between services, and wouldn't require me to create an account with the
> > hosting provider you happen to favour, or the other way around. The
> > issue with e-mail gateways is that e-mail clients (and users) are
> > notorously bad at keeping formatting intact, so the e-mail to hosted
> > service direction is pretty unreliable. I would prefer investigating how
> > that could be improved instead of picking which vendor we'll get our
> > handcuffs from, as it would then benefit everybody.
>
> Would it make sense to allow the user to run the web based merge
> request tool locally (think git instaweb), and send it out as an emailed
> patch series?
>
> Gr{oetje,eeting}s,
>
If I understand your suggestion correctly, thats what the tooling
project I posted earlier does. It creates a git porcelain command (git
lab), with (among other subcommands), a git lab createmr command that:
a) uses the gitlab rest api to create a merge request from your local
git tree
and
b) emails the same patch series to a pre-configured list
Neil
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
next prev parent reply other threads:[~2019-09-26 13:43 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-24 18:25 thoughts on a Merge Request based development workflow Neil Horman
2019-09-24 18:37 ` Drew DeVault
2019-09-24 18:53 ` Neil Horman
2019-09-24 20:24 ` Laurent Pinchart
2019-09-24 22:25 ` Neil Horman
2019-09-25 20:50 ` Laurent Pinchart
2019-09-25 21:54 ` Neil Horman
2019-09-26 0:40 ` Neil Horman
2019-09-28 22:58 ` Steven Rostedt
2019-09-28 23:16 ` Dave Airlie
2019-09-28 23:52 ` Steven Rostedt
2019-10-01 3:22 ` Daniel Axtens
2019-10-01 21:14 ` Bjorn Helgaas
2019-09-29 11:57 ` Neil Horman
2019-09-29 12:55 ` Dmitry Vyukov
2019-09-30 1:00 ` Neil Horman
2019-09-30 6:05 ` Dmitry Vyukov
2019-09-30 12:55 ` Neil Horman
2019-09-30 13:20 ` Nicolas Belouin
2019-09-30 13:40 ` Dmitry Vyukov
2019-09-30 21:02 ` Konstantin Ryabitsev
2019-09-30 14:51 ` Theodore Y. Ts'o
2019-09-30 15:15 ` Steven Rostedt
2019-09-30 16:09 ` Geert Uytterhoeven
2019-09-30 20:56 ` Konstantin Ryabitsev
2019-10-08 1:00 ` Stephen Rothwell
2019-09-26 10:23 ` Geert Uytterhoeven
2019-09-26 13:43 ` Neil Horman [this message]
2019-10-07 15:33 ` David Miller
2019-10-07 15:35 ` Drew DeVault
2019-10-07 16:20 ` Neil Horman
2019-10-07 16:24 ` Drew DeVault
2019-10-07 18:43 ` David Miller
2019-10-07 19:24 ` Eric Wong
2019-10-07 15:47 ` Steven Rostedt
2019-10-07 18:40 ` David Miller
2019-10-07 18:45 ` David Miller
2019-10-07 19:21 ` Steven Rostedt
2019-10-07 21:49 ` Theodore Y. Ts'o
2019-10-07 23:00 ` Daniel Axtens
2019-10-08 0:39 ` Eric Wong
2019-10-08 1:26 ` Daniel Axtens
2019-10-08 2:11 ` Eric Wong
2019-10-08 3:24 ` Daniel Axtens
2019-10-08 6:03 ` Eric Wong
2019-10-08 10:06 ` Daniel Axtens
2019-10-08 13:19 ` Steven Rostedt
2019-10-08 18:46 ` Rob Herring
2019-10-08 21:36 ` Eric Wong
2019-10-08 1:17 ` Steven Rostedt
2019-10-08 16:43 ` Don Zickus
2019-10-08 17:17 ` Steven Rostedt
2019-10-08 17:39 ` Don Zickus
2019-10-08 19:05 ` Konstantin Ryabitsev
2019-10-08 20:32 ` Don Zickus
2019-10-08 21:35 ` Konstantin Ryabitsev
2019-10-09 21:50 ` Laura Abbott
2019-10-10 12:48 ` Neil Horman
2019-10-09 21:35 ` Laura Abbott
2019-10-09 21:54 ` Konstantin Ryabitsev
2019-10-09 22:09 ` Laura Abbott
2019-10-09 22:19 ` Dave Airlie
2019-10-09 22:21 ` Eric Wong
2019-10-09 23:56 ` Konstantin Ryabitsev
2019-10-10 0:07 ` Eric Wong
2019-10-10 7:35 ` Nicolas Belouin
2019-10-10 12:53 ` Steven Rostedt
2019-10-10 14:21 ` Dmitry Vyukov
2019-10-11 7:12 ` Nicolas Belouin
2019-10-11 13:56 ` Dmitry Vyukov
2019-10-14 7:31 ` Nicolas Belouin
2019-10-10 17:52 ` Dmitry Vyukov
2019-10-10 20:57 ` Theodore Y. Ts'o
2019-10-11 11:01 ` Dmitry Vyukov
2019-10-11 12:54 ` Theodore Y. Ts'o
2019-10-14 19:08 ` Han-Wen Nienhuys
2019-10-15 1:54 ` Theodore Y. Ts'o
2019-10-15 12:00 ` Daniel Vetter
2019-10-15 13:14 ` Han-Wen Nienhuys
2019-10-15 13:45 ` Daniel Vetter
2019-10-16 18:56 ` Han-Wen Nienhuys
2019-10-16 19:08 ` Mark Brown
2019-10-17 10:22 ` Han-Wen Nienhuys
2019-10-17 11:24 ` Mark Brown
2019-10-17 11:49 ` Daniel Vetter
2019-10-17 12:09 ` Han-Wen Nienhuys
2019-10-17 12:53 ` Daniel Vetter
2019-10-15 16:07 ` Greg KH
2019-10-15 16:35 ` Steven Rostedt
2019-10-15 18:58 ` Han-Wen Nienhuys
2019-10-15 19:33 ` Greg KH
2019-10-15 20:03 ` Mark Brown
2019-10-15 19:50 ` Mark Brown
2019-10-15 18:37 ` Konstantin Ryabitsev
2019-10-15 19:15 ` Han-Wen Nienhuys
2019-10-15 19:35 ` Greg KH
2019-10-15 19:41 ` Konstantin Ryabitsev
2019-10-16 18:33 ` Han-Wen Nienhuys
2019-10-09 2:02 ` Daniel Axtens
2019-09-24 23:15 ` David Rientjes
2019-09-25 6:35 ` Toke Høiland-Jørgensen
2019-09-25 10:49 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190926134225.GA7235@hmswarspite.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=geert@linux-m68k.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=sir@cmpwn.com \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).