git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: Sebastian Schuberth <sschuberth@gmail.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, patchwork@lists.ozlabs.org
Subject: Re: Pain points in Git's patch flow
Date: Mon, 19 Apr 2021 19:36:00 +0000	[thread overview]
Message-ID: <20210419193600.GA19186@dcvr> (raw)
In-Reply-To: <CAHGBnuOVmzzhgW6GanHBXNb22UW3P1m3i6PJnOUEhYPO76hH4g@mail.gmail.com>

Sebastian Schuberth <sschuberth@gmail.com> wrote:
> On Sun, Apr 18, 2021 at 10:54 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
> 
> > And thank you for participating in the discussion. I think it's
> > especially valuable to get a viewpoint like yours, i.e. someone who (per
> > this E-Mail below) gave up in frustration with the current development
> > flow.
> 
> To be fair, Git's contribution flow isn't the only reason why I chose
> to stop contributing. Another reason is the very lengthy and tedious
> discussions that too often spark from rather small changes.
> 
> Also, I wouldn't say I "gave up in frustration". It was a mostly
> unemotional decision on which of the many OSS projects I contribute to
> my rare spare time is spent best.

I guess some things aren't for everybody.  When I started
git-svn, I never expected git to be the right tool for others.
I figured most folks could just continue using SVN since they
seem to like centralized things or at least have some sort of
"authority" to look to.

I'm largely uninvolved with git nowadays since I'm reasonably
satisfied with how it works; that and I prefer scripting
languages rather than ahead-of-time languages.

> > Rather it's that it's a volunteer project and people work on what
> > they're interested in.
> 
> Exactly. That's why I believe tooling should allow people to subscribe
> to changes in code areas they're interested in, rather than a
> contributor having to know which subsystem maintainer to put in CC
> (e.g. for gitk changes). At least at the time when I contributed it
> was sometimes hard to move things forward if you didn't reach out to
> the right people.

Fwiw, any public-inbox endpoint with Xapian search enabled lets
you request an Atom feed via "x=A" query parameter.

To watch a particular filename, the "dfn:" prefix may be used.
The prefixes supported for a particular instance are documented in
<https://public-inbox.org/git/_/text/help/>, and you
can watch multiple files by combining with "OR".

https://public-inbox.org/git/?q=dfn:cache.h+OR+dfn:git-send-email.perl&x=A

You can also POST to get a gzipped mboxrd file:

curl -d '' \
  'https://public-inbox.org/git/?q=dfn:cache.h+OR+dfn:git-send-email.perl&x=m'

> > of these proposed alternatives involve moving away from something that's
> > a distributed system today (E-Mail infrastructure, local clients), to
> > what's essentially some website run by a centralized entity, in some
> > cases proprietary.
> 
> That's a good point, I admit I haven't thought of that. Probably
> because I also don't care much. So *does* it really matter? What
> exactly concerns you about a "centralized entity"? Is it the technical
> aspect of a single point of failure, or the political / social aspect
> of being dependent on someone you do not want to get influenced by? I
> guess it's a bit of both.

Yes, both for me.  The political/social aspect is the main
reason I'm involved with DVCS (and a large part of why I'm
involved with free software in general).

> While these concerns could probably be addressed somewhat e.g. by
> multiple independently operated Gerrit servers that are kept in sync,
> I was curious and quickly search for more fitting "truly
> decentralized" solutions, and came across radicle [1]. Just FYI.

I don't think any sort of radicle "flag day" or tool mandate is
going to fly.  I seem to recall at least one prominent Linux
kernel hacker doesn't even use git; though I'm not sure if
that's still the case.

Despite being a DVCS user even pre-git, I'm actually
pessimistic about decentralization protocols that either:

1) rely on planet-destroying proof-of-work schemes

2) will need to reinvent the spam filtering techniques
   of email once they hit critical mass

Email is already well-established with a good amount of small
players, and plain-text is relatively inexpensive.  So it seems
best to build off the only halfway-decentralized thing we have
in wide use, rather than trying to start from scratch.

  parent reply	other threads:[~2021-04-19 19:36 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
2021-04-30 20:45               ` Felipe Contreras
2021-04-20 10:34           ` Ævar Arnfjörð Bjarmason
2021-04-19 19:36       ` Eric Wong [this message]
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=20210419193600.GA19186@dcvr \
    --to=e@80x24.org \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=patchwork@lists.ozlabs.org \
    --cc=sschuberth@gmail.com \
    --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).