From: "Theodore Ts'o" <firstname.lastname@example.org> To: Sebastian Schuberth <email@example.com> Cc: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org>, "Git Mailing List" <email@example.com>, firstname.lastname@example.org Subject: Re: Pain points in Git's patch flow Date: Mon, 19 Apr 2021 18:34:17 -0400 [thread overview] Message-ID: <YH4FaQRB/vWOI9aI@mit.edu> (raw) In-Reply-To: <CAHGBnuMedez4SE-4-JwCcR8k=_FRtjgBdBSEJqshQnVceCvGug@mail.gmail.com> On Mon, Apr 19, 2021 at 09:23:14PM +0200, Sebastian Schuberth wrote: > > 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? Linus mostly pulls from git trees. The e-mail workflow tends to be used by maintainers, who are reviewing submissions from their contributors. People submitting changes relating to ext4 know to send it to the linux-ext4 mailing list; people who are submitting changes to the xfs file system send it to linux-xfs, etc. > > 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. The primary reason why the kernel uses mailing lists is because code reviews are fundamentally *discussions*, and people are used to using inboxes. Sure, you can have a gerrit server send e-mail notifications about code reviews, but then you have to reply by going to the gerrit server (and gerrit really doesn't work well on slow network link such as those found on airplanes and cruise ships). I'd say that most maintainers simply find e-mail reviews to simply be more *convenient* than using gerrit. And over time, we've used other tools to track metadata over the status of a patch, such as patchwork, which are optional. > > 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. I'll note that the kernel folks have done this, starting with a 2019 Kernel Summit talk at the Linux Plumbers Conference in Lisbon. A description of the follow-up discussions from that talk can be found here: https://lwn.net/Articles/803619/ There was a collection of requirements on a thread on the newly created email@example.com mailing list. This has led to a number of proposals to make improvements to git, public-inbox, patchwork, the kernel.org infrastructures, etc., some of which were funded by the Linux Foundation last year. Konstantin Ryabitsev has been driving a large amount of that work, and one of the things that has come out of that is b4. (Yes, that's a Star Trek reference... https://memory-alpha.fandom.com/wiki/B-4) https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation Obviously, this isn't intended to be a solution for everyone, and I'm sure there are many projects that are happy forcing developers to use, say, Gerrit, which might be a better solution for them. However, there are a number of core kernel developers who are super-allergic to solutions which force users to use web interfaces. So solutions that have a combination of CLI's as well as web interface is probably going to be the right approach. Things like pwclient and b4 are exciting starting points for improved kernel workflows. Of course, we've gone a bit farther afield from the original question which is what should git's development workflows should be. Given that git is using some of the kernel.org infrastructures, certainly some of the kernel workflow tools are options for the git development community to consider. One of the advantages of the kernel workflows model is that we don't force users to use github or gitlab or gerrit, without having to make a global decision for the entire community. For example, if some developers want to start using b4 to download patch series for git, they could start doing that today. Cheers, - Ted
next prev parent reply other threads:[~2021-04-19 22:34 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 [this message] 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=YH4FaQRB/vWOI9aI@mit.edu \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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).