list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: "brian m. carlson" <>
Cc: Jonathan Nieder <>,, Raxel Gutierrez <>,,,
	Junio C Hamano <>, Taylor Blau <>,
	Emily Shaffer <>
Subject: Re: Pain points in Git's patch flow
Date: Mon, 26 Apr 2021 16:36:19 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

> [[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/ (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.

  parent reply	other threads:[~2021-04-26 14:53 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
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 [this message]
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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: Pain points in Git'\''s patch flow' \

* 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:

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