git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Sebastian Schuberth <sschuberth@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>, patchwork@lists.ozlabs.org
Subject: Re: Pain points in Git's patch flow
Date: Mon, 19 Apr 2021 21:23:14 +0200	[thread overview]
Message-ID: <CAHGBnuMedez4SE-4-JwCcR8k=_FRtjgBdBSEJqshQnVceCvGug@mail.gmail.com> (raw)
In-Reply-To: <87czuq4r4l.fsf@evledraar.gmail.com>

On Mon, Apr 19, 2021 at 10:26 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:

> > If you send around code patches by mail instead of directly working on
> > Git repos plus some UI, that feels to me like serializing a data class
> > instance to JSON, printing the JSON string to paper, taking that sheet
> > of paper to another PC with a scanner, using OCR to scan it into a
> > JSON string, and then deserialize it again to a new data class
> > instance, when you could have just a REST API to push the data from on
> > PC to the other.
>
> 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?

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

> To begin with if we'd have used the bugtracker solution from the
> beginning we'd probably be talking about moving away from Bugzilla
> now. I.e. using those things means your data becomes entangled with the
> their opinionated data models.

Indeed, it's an art to choose the right tool at the time, and to
ensure you're not running into some "vendor-lock-in" if data export is
made too hard. And aligning on someone's "opinionated data model" is
not necessarily a bad thing, as standardization can also help
interoperability and to smoothen workflows.

> > Not necessarily. As many of these tools have (REST) APIs, also
> > different API clients exist that you could try.
>
> API use that usually (always?) requires an account/EULA with some entity
> holding the data, and as a practical concern getting all the data is
> usually some huge number of API requests.

I'm not sure how relevant that concern really is, but in any cause it
would be irrelevant for a self-hosted solution.

> >> And to e.g. as one good example to use (as is the common convention on
> >> this list) git-range-diff to display a diff to the "last rebased
> >> revision" would mean some long feature cycle in those tools, if they're
> >> even interested in implementing such a thing at all.
> >
> > AFAIK Gerrit can already do that.
>
> Sure, FWIW the point was that you needed Gerrit to implement that, and
> to suggest what if they weren't interested. Would you need to maintain a
> forked Gerrit?

Sorry, I can't follow that. Why would you need to maintain a fork of
Gerrit if Gerrit already has the feature you're looking for? Is it a
hypothetical question about what to do if Gerrit would not have the
feature yet?

> Anyway, as before don't take any of the above as arguing, FWIW I
> wouldn't mind using one of these websites overall if it helped
> development velocity in the project.

I appreciate that open mindset of yours here.

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

-- 
Sebastian Schuberth

  reply	other threads:[~2021-04-19 19:23 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 [this message]
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='CAHGBnuMedez4SE-4-JwCcR8k=_FRtjgBdBSEJqshQnVceCvGug@mail.gmail.com' \
    --to=sschuberth@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=patchwork@lists.ozlabs.org \
    --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).