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

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

[Konstantin Ryabitsev]

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 20220830233129.30610-1-samitolvanen@google.com
	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/samitolvanen@google.com
	  ✓ 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 20220830233129.30610-1-samitolvanen@google.com
	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 <nathan@kernel.org> (✓ DKIM/kernel.org)
		+ Tested-by: Kees Cook <keescook@chromium.org> (✓ DKIM/chromium.org)
	
	  [...]
	
	  x86: Add support for CONFIG_CFI_CLANG
		+ Reviewed-by: Kees Cook <keescook@chromium.org> (✓ DKIM/chromium.org)
		+ Tested-by: Nathan Chancellor <nathan@kernel.org> (✓ DKIM/kernel.org)
		+ Tested-by: Kees Cook <keescook@chromium.org> (✓ 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.:

	Fixes: abcde (Commit info)
	Suggested-by: Rep Orter <rep.orter@exmple.com>
	Signed-off-by: Dev Eloper <dev.eloper@example.com>
	--> start of your own custody section
	Link: https://msgid.link/some@thing.foo
	Acked-by: Collected Trailer 1 <collected1@example.com>
	Reviewed-by: Collected Trailer 2 <collected2@example.com>
	Tested-by: Collected Trailer 3 <collected3@example.com>
	Signed-off-by: Your Name <your.name@example.com>
	--> 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 = dev.eloper@example.com
	  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 <devnull@kernel.org>"
   - We add "X-Original-From: Your Name <your-actual@address.com>"
   - We add "Reply-To: Your Name <your-actual@address.com>"
   - We add "From: Your Name <your-actual@address.com>" 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 tools@linux.kernel.org. I greatly
appreciate your help getting these new features ready before we open this up
to a larger set of people.

Best regards,
Konstantin

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

[Geert Uytterhoeven]

Hi Konstantin,

On Fri, Sep 2, 2022 at 9:16 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> 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.

Thanks for your continued work!

> 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.:
>
>         Fixes: abcde (Commit info)
>         Suggested-by: Rep Orter <rep.orter@exmple.com>
>         Signed-off-by: Dev Eloper <dev.eloper@example.com>
>         --> start of your own custody section
>         Link: https://msgid.link/some@thing.foo
>         Acked-by: Collected Trailer 1 <collected1@example.com>
>         Reviewed-by: Collected Trailer 2 <collected2@example.com>
>         Tested-by: Collected Trailer 3 <collected3@example.com>
>         Signed-off-by: Your Name <your.name@example.com>
>         --> end of your own custody section

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

> 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

... 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 -- geert@linux-m68k.org

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