From: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org> To: "brian m. carlson" <email@example.com> Cc: Jonathan Nieder <firstname.lastname@example.org>, email@example.com, Raxel Gutierrez <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Junio C Hamano <email@example.com>, Taylor Blau <firstname.lastname@example.org>, Emily Shaffer <email@example.com> Subject: Re: Pain points in Git's patch flow Date: Mon, 26 Apr 2021 16:36:19 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <YIYfsMsz0Uz48GaI@camp.crustytoothpaste.net> 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/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.
next prev 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: 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).