Re: Pain points in Git's patch flow

From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Apr 19, 2021, 05:54 UTC
Message-ID: <CAHGBnuOVmzzhgW6GanHBXNb22UW3P1m3i6PJnOUEhYPO76hH4g@mail.gmail.com>
In-Reply-To: <87fszn48lh.fsf@evledraar.gmail.com>

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 think it's important not to conflate tooling issues with social
> issues. It's not that we e.g. couldn't whip up a quick script to

I'm not sure I agree completely here, because some tools make it easier to overcome social issues than others.

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

> So maybe having assigned reviewers would help move things along. But I
> wonder if it wouldn't also lead down the rut of PRs/MRs languishing for
> months, because the reviewers just want to spend their time in some
> other way.

Having default assignees for reviews / code owners / however you want to call it does not mean that only these people should review, or that something cannot be merged without their review. It just makes it more clear who's opinion would be the best to get, and who should execute a "word of command" if things do not move forward.

> I.e. the design of many of these tools in this regard assumes you have a
> workforce, not the cat-herding problem of volunteers working on whatever
> strikes their fancy.

E.g. GitHub makes the distinction between "reviewers" for a PR and "assignees" for a PR, and the former can be configured from a CODEOWNERS file. In projects I contribute to on GitHub, "reviewers" are used as an optional list of named reviewers, i.e. these people are explicitly invited for a review. There's no obligation to review, though. On the other hand, if there are additional "assignees", these people are explicitly asked for a review. Assignees can also be assigned only at a later stage of the review, to "settle" a discussion.

The cat-herd of volunteers would neither be "reviewers" nor "assignees", but they would just browse the list or open PRs can jump it where they want to.

> I think characterizing E-Mail as a "legacy" workflow isn't accurate. All

I admit it was a deliberately provocative choice of words, well knowing it's not reflecting the current state, to underline how I'm feeling about the workflow. E-mail is great. Also plain text e-mail is great (I've configured all my client to only send plain text), but please, not for sending around code patches.

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.

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

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.

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

Not necessarily. As many of these tools have (REST) APIs, also different API clients exist that you could try.

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

-- 
Sebastian Schuberth