Re: Review process improvements

On Thu, Dec 16, 2021 at 02:46:21PM -0800, Emily Shaffer wrote:

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

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