On Thu, Dec 16, 2021 at 02:46:21PM -0800, Emily Shaffer wrote:
> Some of those discussions resulted in changes - for example,
> GitGitGadget was improved and added to git/git, and we enjoy easy,
> non-noisy CI runs via GitHub Actions. But some things we thought were a
> good idea never went into practice. In the next few months, the Google
> Git team is planning to implement some of the following changes, and
> we'd appreciate your thoughts ahead of time as well as your review later
> on:
I'd like to also mention that I'm hoping to add a few more features to b4 that
will hopefully improve the patch submission process for folks. This feature
set is far from being complete yet, but the gist will be as follows:
1. b4 submit --new: this will create a new tracking branch and define
some metadata to go with it, such as a cover letter template. The cover
letter can be edited using `b4 submit --edit-cover` at any time.
2. b4 submit --send: will generate a patch series from any commits created
from the topical branch fork point and use the cover letter from the
previous step. It will be able to send the patches using the traditional
SMTP way, OR it will allow using a web-based submission service I'm setting
up at kernel.org:
- anyone will be able to submit valid patches through this service
- one-off patch submissions will require an email confirmation roundtrip
- any submitter can also register their ed25519/openssh patatt key with the
submission service and just cryptographically sign their patches. As long
as signatures validate, no roundtrip confirmation of patches will be
required after the initial public key registration.
- on the receiving end, the patches will be written to a dedicated
lore.kernel.org feed *as-is*, but also sent to the recipients after doing
the usual From/Reply-To substitution and moving the original From into
the in-body git headers (i.e. same as GGG does).
3. b4 submit will properly include base-commit information to all submitted
patches, as well as a unique change-id trailer (but in the basement of the
cover letter, not in the commit message trailers as Gerrit does).
4. b4 submit --sync: will retrieve any received code review trailers
(reviewed-by, acked-by, etc) and amend the corresponding commits in the
topical branch, assuming we can match patch-id's (I've not tackled this
yet, so I may be unduly optimistic here).
5. b4 submit --reroll: will prepare a v2 (v3, v4) of the series, reusing the
same change-id trailer and adding a templated "Changes in v2" entry to the
cover letter (that must be edited before --send works again).
6. b4 submit --send: will send the new version of the series.
I'm hoping that this will improve the experience of patch submitters *and*
help ensure that CI can be incorporated into the process by streamlining the
submission procedure and providing a public-inbox feed that can be easily
monitored. A service like GGG can fairly easily convert well-formed patch
series (at least those carrying valid base-commit info) into ephemeral
worktrees, or even into simulated pull requests if the goal is to do this via
a generic CI service.
The important goal is to keep development fully decentralized so that even if
the web submission endpoint provided by kernel.org becomes unavailable, plain
old SMTP submission mechanisms can still be used as a fallback.
(Unfortunately, I need to focus my efforts on some kernel.org infrastructure
changes at this time, so I'm not sure when I'll be able to complete these
features.)
> 1. Draft a MAINTAINERS file
So, I *don't* recommend that you go this route. The biggest problem with the
MAINTAINERS file as used by the Linux development community is that making
changes to it is a very high-latency process. It will be less of a problem for
the much smaller git developer community, but it will still result in folks
operating from a stale copy of the file for weeks after it is updated
upstream.
One of the goals behind the "lei" tool by public-inbox is that it allows
search-based subscriptions (including things like "what files are being
modified, what functions are mentioned in the git context", etc). Anyone can
define a set of parameters they are interested in monitoring and receive only
threads matching those pre-filtered messages. We are currently rolling this
out as an end-user maintained setup [1], but the goal is to also offer this to
maintainers as a centrally managed service:
- maintainers will be able to define the search queries they are interested in
monitoring
- we will set up a feed on our end matching those queries
- we will offer the feed as a separate public-inbox repository, a public IMAP
folder, a read-only mailing list, and, I'm hoping, a read-only POP box (the
latter mostly so it can be configured to feed into GMail).
The hope is that this will allow what you're looking for -- a way to
pre-filter the flow of patches to maintainers by making it topical, without
making the lives of patch submitters unnecessarily difficult by increasing the
chances that they will send their patches to the wrong list.
[1] https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started
I'm not sure where this all fits into your plans, but I wanted to show what is
happening on our end just so we're working in parallel, as opposed to in our
own separate worlds. :)
Best regards,
-K
