Re: Pain points in Git's patch flow

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 26, 2021, 14:36 UTC
Message-ID: <87fszd3xo0.fsf@evledraar.gmail.com>
In-Reply-To: <YIYfsMsz0Uz48GaI@camp.crustytoothpaste.net>

On Mon, Apr 26 2021, brian m. carlson wrote:

Show 33 quoted lines

> [[PGP Signed Part:Undecided]]
> On 2021-04-14 at 06:13:26, Jonathan Nieder wrote:
>> [...]
>>  4. What other tools would you like to see that could help?
>
> I think we definitely need a bug tracker.  We extremely frequently lose
> bugs and feature requests on the list and people aren't very likely to
> search the list.  If we could use the same one as someone else, such as
> the kernel, that would be ideal, because it means people are more likely
> to already have an account and therefore the friction to report a bug is
> lower.  Alternatively, we could use something like debbugs which is
> controllable entirely by email and therefore requires no accounts (but
> does require someone to occasionally prune reported spam).
>
> I know full well why we don't use a forge-based model and I'm not
> recommending that, but I do want to point out that forges solve all of
> my pain points, and I do have a much quicker turnaround time on patches
> when I'm using a forge.  So ideally we'd have some standard or
> recommended tooling, whether built by us or by others (e.g., an open
> source project for patch workflows), that addresses these pain points so
> that everyone doesn't have to build their own and turnaround time can be
> improved.
>
> I have seen replies downthread that some developers really are reticent
> to use more common tooling, like web interfaces.  While I do want to
> keep our project as accessible as possible to as many people as
> possible, I worry that by catering to folks who don't want to adopt this
> tooling, we are drastically reducing the number of possible contributors
> of all sorts (code authors, documentation writers, bug reporters) by
> not doing so and worsening our own experience in many ways.  I do think
> we should adopt modern tooling (e.g., web interfaces) provided that it
> is usable for people with accessibility needs, even if that makes some
> people unhappy.

I'm not disagreeing, just replying to point out that I think for your suggestion & others having as much of a split as possible between "what" and "how" would, I think, be useful in moving things along.

A web interface is a "how", but it's also implicitly a "what" in the way that most people think about it in this context.

I.e. it's not like we couldn't have a bug tracker now using the ML, you'd send a patch, Junio would pick up the report and we'd drop it into bug/some-description.md (with some handwaiving for formatting, merge conflicts etc.). We'd remember bug reports, feature requests etc. forever, and patches could atomically change/close/remove those as they fix/change/implement them.

The point I'm getting at is that the "what" we're also implicitly discussing is the developer community shouldering the burden of keeping such a tracker and the information within it up-to-date.

A web-based interface that worked like our mailing list does now would be one that, say, deleted your bug 30 days of inactivity (or otherwise made it as "archived" as something in the ML lore).

I couldn't find a reference to it now, but as I recall (and maybe I wrote some) there's been some prominent defenses of this model of development in the past.

I.e. it puts the onus on reporters to make sure their issue is being addressed, if nobody cares to pick it up it probably wasn't that important, and we shouldn't so lightly assume the fixed cost of adding that one-off report to an ever-growing list of reports we'd need to continually look at / curate / keep up to date etc.

But none of that's an argument I'm looking to get into right now, or really have much of a firm stance on. I just wanted to point out that it's a clear case where a "what" is being conflated with a "how".

I.e. we're implicitly not only talking about how something gets done, but a big change in what gets done.

I had a similar comment upthread (or in a side-thread) about how much of the suggestions of making use of the various reviewer/approver PR/MR/whatever tools in the wild seem to simply assume a move away from the long-time model where there's effectively only one approver/merge master/committer (i.e. Junio). That's an entirely defensible argument, but another case of making a "how" and "what" argument at the same time.

Maybe the people proposing both a "how" and a "what" will have an easier time if those are untangled, and we change one thing at a time.