git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Sebastian Schuberth <sschuberth@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	patchwork@lists.ozlabs.org
Subject: Re: Pain points in Git's patch flow
Date: Tue, 20 Apr 2021 08:30:57 +0200	[thread overview]
Message-ID: <CAHGBnuNrXrHUz9f8nWEdB0PoO0FeLsNpNOGgdiYmsmAD5LjTmg@mail.gmail.com> (raw)
In-Reply-To: <YH4FaQRB/vWOI9aI@mit.edu>

On Tue, Apr 20, 2021 at 12:34 AM Theodore Ts'o <tytso@mit.edu> wrote:

> 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

[...]

> maintainers simply find e-mail reviews to simply be more *convenient*
> than using gerrit.  And over time, we've used other tools to track

That still sounds to me as if people are stuck to what they know.
Maintainers are "used to using inboxes'', and that's *why* they find
e-mail reviews to be convenient.

Of course, there's basically nothing wrong with sticking to a flow
that works. But I understood the start of this discussion as a sign
that you guys acknowledge that something does *not* work. At least not
when it comes to attracting new contributors.

> 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
> here:

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?

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.

And, please don't take anything I've written as a try to talk you into
anything. But as the lead of a team who's day job it is to contribute
to various Open Source projects, I believe to have a good feeling
about what the pain points of developers are to start contributing.
I'm just trying to foster some appreciation for the thinking of the
"other side".

-- 
Sebastian Schuberth

  reply	other threads:[~2021-04-20  6:31 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 [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=CAHGBnuNrXrHUz9f8nWEdB0PoO0FeLsNpNOGgdiYmsmAD5LjTmg@mail.gmail.com \
    --to=sschuberth@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=patchwork@lists.ozlabs.org \
    --cc=tytso@mit.edu \
    --subject='Re: Pain points in Git'\''s patch flow' \
    /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

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

	https://80x24.org/mirrors/git.git

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).