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: Tue, 20 Apr 2021 12:37:04 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Apr 20, 2021 at 08:30:57AM +0200, Sebastian Schuberth wrote:
> I'm reading a lot about "maintainers" and "kernel developers" here.
> But what I believe is important to accept is that Git is not only
> about kernel development anymore. While I'm well aware of Git's
> history, there are by far more people using Git than there are kernel
> developers, and also by lines of code (or whatever "stupid" metric you
> want to choose) the kernel is not the biggest project maintained in
> Git. Maybe not even the most important one, but that's highly
> subjective anyway. So asked in a heretic way, why should the opinion
> of a kernel developer count more than the opinion of, say, an Eclipse
> Foundation developer when it comes to Git workflow questions?

I think it should be up to each development community to decide what
workflows makes sense for that community.

The kernel community has been taking requirements for what works well
for *that* community, and we've found companies who are willing to
fund improvements in the tools that we use (which include git,
public-inbox, patchwork, etc.) so that it can meet our needs.

Our approach is that we don't want to *force* everyone to switch to
some web interface.  Instead, instead of either-or, we're looking for
some kind both/and, so we don't have to insult people who are
*extremely* productive with an e-mail workflow by calling them
dinosaurs, and force them to use a web interface which would make them
much less productive, on the hope that maybe we would get some more
new contributors.  (And at least for the kernel, we're blessed by the
fact that there is no shortage of new contributors; so our goals are
to make *everyone* more productive, and not have an attitude of "you
shall use gerrit/github and everyone else can go suck wind".)

Git is going to have to decide what development workflows will work
well for its development community.  Historically, since git was
originally authored by Linus Torvalds, it's not surprising that there
is a bias towards an e-mail workflow.  Indeed, git commands like "git
send-email" and "git apply-mbox" are there from the very beginning
because it was *designed* to work well with the kernel workflow.

> To me, that means if you want to make contributions to Git more
> attractive to the Git community beyond the kernel, you need to stop
> making incremental improvements to existing tools and start thinking
> out of the box by looking at the tools that are most popular in that
> "other side" of the community.

I'm not sure that's what was meant by the question of pain points in
Git's patch flow.  Your perspective is certainly a valid one, and it's
certainly easier to choose sides and make an opinioned decision which
disenfranches "one side" of the community in favor of the "other side"
of the community.

It's not the approach that was adopted by the folks who are working on
improving the Kernel development workflows.  The git development
community will need what approach makes sense for it.


						- Ted

  reply	other threads:[~2021-04-20 16:37 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
2021-04-20  6:30             ` Sebastian Schuberth
2021-04-20 16:37               ` Theodore Ts'o [this message]
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 \ \ \ \ \ \ \
    --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).