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

Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Sun, Apr 18 2021, Sebastian Schuberth wrote:
> 
> > On 2021-04-14 08:13, Jonathan Nieder wrote:
> >
> >> Those four are important in my everyday life.  Questions:
> >
> > Thanks for bringing up these questions in a dedicated format. I'll
> > take this as an opportunity to share my thoughts on this topic, which
> > have accompanied me for quite a while.
> 
> 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.

Agreed

> The below isn't meant as a retort, but to hopefully clarify things a
> bit.

Some further clarifications on my part below.

<snip some of Ævar's excellent clarifications>

> > Sure, I get that that the contribution workflow to Git core has
> > historically grown, but what concerns me is that the efforts to
> > "bridge" the contribution workflow to the "modern world" seem to go
> > into the wrong direction: Tools like submitgit [1], gitgitgadget [2]
> > and now patchwork [3] were created / are considered for use to allow
> > the legacy email path workflow to remain, but also allow more "GUI
> > minded" people to contribute. While this has worked quite well for
> > some time, and esp. gitgitgadget [2] seems to haven gotten popular, I
> > wonder whether it's now the time to "swap the default", and make a
> > patch / contribution tool with a GUI the standard, and bridge the
> > legacy workflow by using / creating tooling that makes it convenient
> > to use those modern tools from the CLI, instead of the opposite.
> 
> I think characterizing E-Mail as a "legacy" workflow isn't accurate. All
> 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.
> 
> Even in cases where the tool itself isn't proprietary (e.g. GitLab
> instead of GitHub) using GitHub/GitLab/Gerrit/Atlassian Bitbucket
> etc. means having some centralized infrastructure somewhere holding a
> bunch of data only the operator of that infrastructure can realistically
> access.

Thanks all for bringing this up.  I should add the mail archives
at lore.kernel.org are backed by public-inbox, thus all mail and
code are completely reproducible by anyone.  It even targets
old, slow, legacy hardware and tries to minimize bandwidth to
benefit the economically-disadvantaged.

Forking is the checks-and-balances system of free software to
prevent any central entity from becoming too powerful (remember:
power corrupts).  DVCS (e.g. git) makes forking easier,
public-inbox uses git to make text communications history
reproducible (and therefore, forkable).  My end goal is
completely forkable communities without any central arbiters.

Email has problems, of course.  Big players are constantly
introducing more complexity to squeeze out smaller players.
And most mail servers require DNS through ICANN, an organization
that tried to extort .org users and hence likely to attempt
further abuses of power in the future.  Again, power corrupts.

> So really basic things that are comparatively trivial with E-Mail
> (e.g. "I think the search sucks, try another client") run up against a
> brick wall with those tools.

I'm working on some local tooling based on public-inbox ;)
(of course, totally optional)

And public-inbox will support JMAP in coming months, so it'll
be a standardized API and hopefully compatible with a wider
variety of clients and frontends.  This should help users who
prefer other other layouts.


Anyways, I do what I can to keep hardware and bandwidth
requirements low for folks who:
a) can't afford to keep up with Moore's law
b) won't accept mystery firmware blobs in modern HW
I got into free software because HW was constantly obsoleted by
proprietary software; and I'm sad so much "modern" free software
has followed that path...

The modern web is largely unusable with HW I first tried git
with in 2005.  Despite being technically free software, the size
of "modern" browsers makes it impractical for people on slow
HW/connections to actually exercise software freedom.  IMHO, any
HW that worked well in 2005 when git started ought to work well
for git and anything associated with it today.

  reply	other threads:[~2021-04-19  2:58 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 [this message]
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
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=20210419025842.GA15976@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).