git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nico Williams <nico@cryptonector.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Hans Meiser <brille1@hotmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Migrate away from vger to GitHub or (on-premise) GitLab?
Date: Thu, 1 Feb 2024 11:46:39 -0600	[thread overview]
Message-ID: <ZbvY/01kebuFagn2@ubby> (raw)
In-Reply-To: <20240201-primitive-aardwark-of-contentment-aaabb9@lemur>

On Thu, Feb 01, 2024 at 10:39:04AM -0500, Konstantin Ryabitsev wrote:
> [excellent discussion of e-mail workflows elided]

It would surely help if the e-mail interfaces of forges were not
terrible.  But they really have to be as good as the mailing list
approach.

I envision that the "issues" and "PRs" could be webmail-ish thread
trackers that auto-close on prolonged silence.  One could open issues/
PRs by e-mail, close them by e-mail, etc., all e-mails going to the same
[forge-run?] list address, but still have a forge-style view of a PR's
commits, still have a forge-style code review web UI (with all comments
going to e-mail too, and with e-mail being first-class, not an
afterthought), still have a CI checks UI, and still have a big
rebase-and-merge button for maintainers.

I.e., forge e-mail UI as first-class equivalent of forge web UI.

The forges tend to be run by people who prioritize users who are not
heavy e-mail workflow devs.  It makes economic sense, given how few
users demand e-mail as a first-class forge UI.  Still, it would be quite
awesome if some forge did this.

> - How to avoid a vendor lock-in? [...]

Assuming some forge exists with an e-mail UI on the same footing as its
web UI, and also good enough for kernel/git/... devs, you could maintain
mirrors on all the other forges, naturally, and always fallback on
e-mail only if the primary forge disappears or becomes too expensive.

> - How to avoid centralization and single points of failure? [...]

It's all forks, all the time.  It'd be good if the kernel maintainers
maintained non-forge git servers as mirror/staging/primary repos.

> - How to avoid alienating these hundreds of key maintainers who are now
>   extremely proficient at their query-based workflows? [...]

The only answer is to stick to the current workflow until some forge
provide an equivalently first-class e-mail interface.  New participants
just have to get used to it.  IMO.

Nico
-- 

  parent reply	other threads:[~2024-02-01 17:46 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AS2P195MB21350F44B079009C05A1EAF1E2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM>
2024-02-01 12:10 ` Migrate away from vger to GitHub or (on-premise) GitLab? Hans Meiser
2024-02-01 12:20   ` Antonin Delpeuch
2024-02-01 12:21   ` Kristoffer Haugsbakk
2024-02-01 17:39     ` Hans Meiser
2024-02-01 12:56   ` Dragan Simic
2024-02-01 15:39   ` Konstantin Ryabitsev
2024-02-01 16:54     ` Dragan Simic
2024-02-01 17:00       ` Dragan Simic
2024-02-01 17:28     ` Hans Meiser
2024-02-01 17:49       ` Dragan Simic
2024-02-01 18:36         ` Hans Meiser
2024-02-01 19:00           ` Dragan Simic
2024-02-01 20:01             ` rsbecker
2024-02-01 20:09               ` Dragan Simic
2024-02-02 10:21               ` Hans Meiser
2024-02-02 10:18             ` Hans Meiser
2024-02-02 10:54               ` Dragan Simic
2024-02-02 11:23                 ` Muting and unmuting threads (Was: Migrate away from vger to GitHub or (on-premise) GitLab?) Dragan Simic
2024-02-02 11:07             ` Migrate away from vger to GitHub or (on-premise) GitLab? Phillip Wood
2024-02-02 11:13               ` Dragan Simic
2024-02-02 19:02               ` Junio C Hamano
2024-02-02  1:44           ` brian m. carlson
2024-02-02  5:10             ` Patrick Steinhardt
2024-02-02 11:15               ` Phillip Wood
2024-02-02 11:50                 ` Michal Suchánek
2024-02-02 12:36                   ` Dragan Simic
2024-02-04 15:12                   ` Oswald Buddenhagen
2024-02-04 15:28                     ` Dragan Simic
2024-02-04 15:51                       ` Michal Suchánek
2024-02-04 15:58                         ` Dragan Simic
2024-02-04 15:47                     ` Michal Suchánek
2024-02-05  1:04                       ` Oswald Buddenhagen
2024-02-02 10:43             ` Hans Meiser
2024-02-02 10:48               ` Hans Meiser
2024-02-01 17:46     ` Nico Williams [this message]
2024-02-01 17:39   ` Kristoffer Haugsbakk
2024-02-02 14:49   ` Sergey Organov
2024-02-02 15:22     ` rsbecker
2024-02-02 16:16       ` Theodore Ts'o
2024-02-02 17:23         ` Michal Suchánek
2024-02-02 19:04         ` Junio C Hamano
2024-02-02 21:28           ` Theodore Ts'o
2024-02-06  7:22             ` Hans Meiser
2024-02-06  8:06               ` Dragan Simic
2024-02-02 16:41       ` Junio C Hamano
2024-02-02 17:06         ` rsbecker
2024-02-02 17:39           ` Junio C Hamano
2024-02-02 17:50             ` rsbecker

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

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

  git send-email \
    --in-reply-to=ZbvY/01kebuFagn2@ubby \
    --to=nico@cryptonector.com \
    --cc=brille1@hotmail.com \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).