list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Theodore Ts'o" <>
To: Sebastian Schuberth <>
Cc: "Ævar Arnfjörð Bjarmason" <>,
	"Git Mailing List" <>,
Subject: Re: Pain points in Git's patch flow
Date: Mon, 19 Apr 2021 18:34:17 -0400	[thread overview]
Message-ID: <YH4FaQRB/> (raw)
In-Reply-To: <>

On Mon, Apr 19, 2021 at 09:23:14PM +0200, Sebastian Schuberth wrote:
> > That's not inherent with the E-Mail workflow, e.g. Linus on the LKML
> > also pulls from remotes.
> Yeah, I was vaguely aware of this. To me, the question is why "also"?
> Why not *only* pull from remotes? What's the feature gap email patches
> try to close?

Linus mostly pulls from git trees.  The e-mail workflow tends to be
used by maintainers, who are reviewing submissions from their
contributors.  People submitting changes relating to ext4 know to send
it to the linux-ext4 mailing list; people who are submitting changes
to the xfs file system send it to linux-xfs, etc.

> > It does ensure that e.g. if someone submits patches and then deletes
> > their GitHub account the patches are still on the ML.
> Ah, so it's basically just about a backup? That could also be solved
> differently by forking / syncing Git repos.

The primary reason why the kernel uses mailing lists is because code
reviews are fundamentally *discussions*, and people are used to using
inboxes.  Sure, you can have a gerrit server send e-mail notifications
about code reviews, but then you have to reply by going to the gerrit
server (and gerrit really doesn't work well on slow network link such
as those found on airplanes and cruise ships).  I'd say that most
maintainers simply find e-mail reviews to simply be more *convenient*
than using gerrit.  And over time, we've used other tools to track
metadata over the status of a patch, such as patchwork, which are

> > I just wanted to help bridge the gap between the distributed E-Mail v.s
> > centralized website flow.
> Maybe, instead of jumping into something like an email vs Gerrit
> discussion, what would help is to get back one step and gather the
> abstract requirements. Then, with a fresh and unbiased mind, look at
> all the tools and infrastructure out there that are able to fulfill
> the needs, and then make a choice.

I'll note that the kernel folks have done this, starting with a 2019
Kernel Summit talk at the Linux Plumbers Conference in Lisbon.  A
description of the follow-up discussions from that talk can be found

There was a collection of requirements on a thread on the newly
created mailing list.  This has led to a
number of proposals to make improvements to git, public-inbox,
patchwork, the infrastructures, etc., some of which were
funded by the Linux Foundation last year.

Konstantin Ryabitsev has been driving a large amount of that work, and
one of the things that has come out of that is b4.  (Yes, that's a
Star Trek reference...

Obviously, this isn't intended to be a solution for everyone, and I'm
sure there are many projects that are happy forcing developers to use,
say, Gerrit, which might be a better solution for them.

However, there are a number of core kernel developers who are
super-allergic to solutions which force users to use web interfaces.
So solutions that have a combination of CLI's as well as web interface
is probably going to be the right approach.  Things like pwclient and
b4 are exciting starting points for improved kernel workflows.

Of course, we've gone a bit farther afield from the original question
which is what should git's development workflows should be.  Given
that git is using some of the infrastructures, certainly
some of the kernel workflow tools are options for the git development
community to consider.

One of the advantages of the kernel workflows model is that we don't
force users to use github or gitlab or gerrit, without having to make
a global decision for the entire community.  For example, if some
developers want to start using b4 to download patch series for git,
they could start doing that today.


						- Ted

  reply	other threads:[~2021-04-19 22:34 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14  6:13 Jonathan Nieder
2021-04-14  7:22 ` Bagas Sanjaya
2021-04-14  8:02   ` Junio C Hamano
2021-04-14 21:42     ` Junio C Hamano
2021-04-15  8:49   ` Denton Liu
2021-04-15  6:06 ` Junio C Hamano
2021-04-15 15:45 ` Son Luong Ngoc
2021-04-19  2:57   ` Eric Wong
2021-04-19 13:35     ` Theodore Ts'o
2021-04-21 10:19     ` Ævar Arnfjörð Bjarmason
2021-04-28  7:21       ` Eric Wong
2021-04-28  7:05     ` Eric Wong
2021-04-15 18:25 ` Atharva Raykar
2021-04-16 19:50 ` Junio C Hamano
2021-04-16 20:25   ` Junio C Hamano
2021-05-02  5:35   ` ZheNing Hu
2021-04-18  8:29 ` Sebastian Schuberth
2021-04-18 20:54   ` Ævar Arnfjörð Bjarmason
2021-04-19  2:58     ` Eric Wong
2021-04-19  5:54     ` Sebastian Schuberth
2021-04-19  6:04       ` Sebastian Schuberth
2021-04-19  8:26       ` Ævar Arnfjörð Bjarmason
2021-04-19 19:23         ` Sebastian Schuberth
2021-04-19 22:34           ` Theodore Ts'o [this message]
2021-04-20  6:30             ` Sebastian Schuberth
2021-04-20 16:37               ` Theodore Ts'o
2021-04-30 20:45               ` Felipe Contreras
2021-04-20 10:34           ` Ævar Arnfjörð Bjarmason
2021-04-19 19:36       ` Eric Wong
2021-04-19 19:49         ` Sebastian Schuberth
2021-04-19 22:00           ` Konstantin Ryabitsev
2021-05-08  2:10             ` dwh
2021-04-19 21:49       ` Konstantin Ryabitsev
2021-04-19 23:03         ` Stephen Smith
2021-05-08  2:08         ` dwh
2021-05-08  4:41           ` Bagas Sanjaya
2021-04-30 20:58       ` Felipe Contreras
2021-04-21  4:46 ` Daniel Axtens
2021-04-26  2:04 ` brian m. carlson
2021-04-26 14:24   ` Theodore Ts'o
2021-04-26 14:36   ` Ævar Arnfjörð Bjarmason
2021-04-28  7:59   ` Eric Wong
2021-04-28 22:44     ` brian m. carlson
2021-04-30 20:16     ` Felipe Contreras
2021-04-30 20:35   ` Felipe Contreras
2021-04-30 21:09 ` Felipe Contreras

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YH4FaQRB/ \ \ \ \ \ \
    --subject='Re: Pain points in Git'\''s patch flow' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

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 read-only IMAP folder(s) and NNTP newsgroup(s).