b4 further beta testing (now with a web submission endpoint)

Hi, all:

The work on b4 send continues and I feel things are getting close to the point where it can be reasonably used in day-to-day work. Special thanks to everyone who trialled this out in the past few weeks despite high chance of things spontaneously exploding.

Here's the latest, if you're interested in trying things again:

b4 prep: preparing your series for submission
---------------------------------------------

- You can now convert any previously sent series into a prep-managed branch using the -F flag. Here's an example with a random series from lkml:

	$ b4 prep -F [email protected]
	Grabbing thread from lore.kernel.org/all/20220830233129.30610-1-samitolvanen%40google.com/t.mbox.gz
	Checking attestation on all messages, may take a moment...
	---
	  ✓ [PATCH v4 1/21] treewide: Filter out CC_FLAGS_CFI
	  ✓ [PATCH v4 2/21] scripts/kallsyms: Ignore __kcfi_typeid_
	  [...]
	  ✓ [PATCH v4 20/21] x86/purgatory: Disable CFI
	  ✓ [PATCH v4 21/21] x86: Add support for CONFIG_CFI_CLANG
	  ---
	  ✓ Signed: openpgp/[email protected]
	  ✓ Signed: DKIM/google.com
	---
	Created new branch b4/kcfi_support
	Applying 21 patches
	---
	Applying: treewide: Filter out CC_FLAGS_CFI
	Applying: scripts/kallsyms: Ignore __kcfi_typeid_
	[...]
	Applying: x86/purgatory: Disable CFI
	Applying: x86: Add support for CONFIG_CFI_CLANG
	---
	NOTE: any follow-up trailers were ignored; apply them with b4 trailers -u

You can now run "b4 prep --edit-cover" to modify the cover letter, and you can run "b4 trailers -u" to grab the latest trailers updates without having to remember the msgid of the thread:

	$ b4 trailers -u
	Calculating patch-ids from 21 commits
	Checking change-id "20220902-kcfi_support-5bb769dfacb5"
	Grabbing search results from lore.kernel.org
	Nothing matching that query.
	Retrieving thread matching [email protected]
	Grabbing thread from lore.kernel.org/all/20220830233129.30610-1-samitolvanen%40google.com/t.mbox.gz
	---
	  treewide: Filter out CC_FLAGS_CFI
		+ Tested-by: Nathan Chancellor <[email protected]> (✓ DKIM/kernel.org)
		+ Tested-by: Kees Cook <[email protected]> (✓ DKIM/chromium.org)

[...]

x86: Add support for CONFIG_CFI_CLANG
+ Reviewed-by: Kees Cook <[email protected]> (✓ DKIM/chromium.org)
+ Tested-by: Nathan Chancellor <[email protected]> (✓ DKIM/kernel.org)
+ Tested-by: Kees Cook <[email protected]> (✓ DKIM/chromium.org)
---
Invoking git-filter-repo to update trailers.
New history written in 1.15 seconds...
Completely finished after 1.46 seconds.
Trailers updated.

b4 trailers: automatically apply latest received trailers
---------------------------------------------------------
The "b4 trailers" command is now hopefully better behaved.

- the --signoff switch is gone, as your own commits should already have your DCO trailer
- any newly received trailers should automatically be inserted above your own Signed-off-by
- the trailer-order config option will only apply to your own section in the trailers, to respect the chain of custody order, e.g.:

--> start of your own custody section

--> end of your own custody section

b4 send: now with web-endpoint support
--------------------------------------
"b4 send" saw the most changes and supports the web submission endpoint. The goal behind this is to make it easier for developers without access to sanely configured SMTP servers to submit valid patch series. Here's how it works:

1. You need to have a valid PGP key (or a valid patatt key). The PGP key doesn't need to be in any web of trust, it just needs to be valid and set up in git as user.signingkey.

2. Add b4.send-endpoint-web to ~/.gitconfig (or .git/config to only enable this for a specific project). E.g.:

[user]
name = Dev Eloper
email = [email protected]
signingkey = ABCDBCDECDEF0123

[b4]
send-endpoint-web = https://lkml.kernel.org/_b4_submit

3. Next, enroll with the endpoint:

	$ b4 send --web-auth-new

This generates a unique challenge that is sent to the user.email address.

4. Once you receive the verification email, run the verify command:

	$ b4 send --web-auth-verify [received-uuid-here]

5. Once this completes, you will be able to send patches via "b4 send"

LIMITATIONS:

1. You can only send patches and cover letters via this service, and one of the to/cc addresses must be a mailing list service that we recognize. Any code-review or other discussions need to continue to happen via your own email client.

2. If your From: is not @kernel.org, @linux.dev, or @linuxfoundation.org, then we will do the necessary From: munging in order to pass DMARC checks on the receiving end:

- From: becomes "From: Your Name via B4 Web Endpoing <[email protected]>"
- We add "X-Original-From: Your Name <[email protected]>"
- We add "Reply-To: Your Name <[email protected]>"
- We add "From: Your Name <[email protected]>" to the message body, if it doesn't already have another From: (for git "Author" purposes)

However, we will write the original version of the email to the public-inbox list, so that if someone runs "b4 am/shazam" on your submission, they will retrieve the unmodified originals without this munging.

b4 send: versioned tagging and --resend
---------------------------------------
After your do a successful "b4 send", the following happens:

- We do some detached HEAD magic to apply your just-sent commits and tag the tip with the cover letter contents. E.g. if your branch is called b4/documentation-changes, we will create an annotated tag "sent/documentation-changes-v1"
- We auto-increment the tracked version and record the message-id of sent series
- We auto-edit the cover letter to create the changelog section with "Changes in vN:" entries, pre-populated with the link to the series you just sent.

If you want to resend a previously sent series, you can just run "b4 send --resend v1", which will use the tag we created during "b4 send" to repopulate the series and the cover letter.

Updating to the latest b4 dev
----------------------------
To update to the latest b4 dev, you need to run it from the git checkout, which is described in the README:
https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/README.rst

Reporting bugs
--------------
Please expect bugs and report them to [email protected]. I greatly appreciate your help getting these new features ready before we open this up to a larger set of people.

Best regards,
Konstantin

Hi Konstantin,

Thanks for your continued work!

I am a bit confused by the order in this example:

1. Any tags sent as replies to the series sent by Dev Eloper should be added below the SoB of Dev Eloper. This is what Dev Eloper does when sending vN+1 of a patch, or what Maint Ainer does, when applying the patch,

2. Any tags sent as replies to the series sent by Your Name should be added below the SoB of Your Name.
This is typically what Continuingdev Eloper does, who took over the work from Dev Eloper, when sending vN+1.

So the above example seems to imply this is the case where Your Name == Maint Ainer...

... while this section suggests Your Name == Dev Eloper (or Continuingdev Eloper)?

AFAIU, "b4 send" is intended to be used by Dev Eloper or Continuingdev Eloper, while Maint Ainer would use "b4 am" instead?

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds