b4 v0.10.1 is available

b4 v0.10.1 is available

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

Hello:

B4 version 0.10.1 is now available. This release contains the following
changes compared to 0.10.0 (among other minor improvements):

- Fixes the crash with "b4 ty" when using a local binary to send mail, and
  generally improves the [sendemail] configuration section compatibility
- The "send" and "prep" commands now properly include diffstats into generated
  patches
- Does not force single-patch series to have a cover letter. The contents of
  the cover letter are now appended to the basement section of the patch.
- Does not force "v1" to be added to the prefixes

For upgrading instructions, please see docs:
https://b4.docs.kernel.org/en/stable-0.10.y/installing.html

Special thanks to the following people for the testing and bugreports:

- Leon Romanovsky <leon@kernel.org>
- Guillaume Ranquet <granquet@baylibre.com>
- Amjad Ouled-Ameur <aouledameur@baylibre.com>
- Dmitry Torokhov <dmitry.torokhov@gmail.com>

Best regards,
Konstantin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: b4 v0.10.1 is available

[Rob Herring]

On Mon, Sep 26, 2022 at 12:29 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hello:
>
> B4 version 0.10.1 is now available. This release contains the following
> changes compared to 0.10.0 (among other minor improvements):
>
> - Fixes the crash with "b4 ty" when using a local binary to send mail, and
>   generally improves the [sendemail] configuration section compatibility
> - The "send" and "prep" commands now properly include diffstats into generated
>   patches
> - Does not force single-patch series to have a cover letter. The contents of
>   the cover letter are now appended to the basement section of the patch.
> - Does not force "v1" to be added to the prefixes
>
> For upgrading instructions, please see docs:
> https://b4.docs.kernel.org/en/stable-0.10.y/installing.html
>
> Special thanks to the following people for the testing and bugreports:

I found a couple of issues with trailers and send. I'm on the current master.

In 'b4 trailers', if the patch id doesn't match exactly and it finds
some trailers, b4 just prints 'No trailer updates found.' which is
misleading. Can it have a fallback to subject matching or at least
print when there isn't an exact match and list the trailers found.
It's quite common to either have minor changes (and a judgement call
on whether tags still apply) or a review that's 'With X fixed,
Reviewed-by: ...".

The 2nd issue is with 'b4 send' and seems to have been introduced
recently. I have a commit msg like this:
"
Some commit

Signed-off-by: ...
---
 v2: https://lore.kernel.org/all/20220909204509.2169512-1-robh@kernel.org/
   - Rework YACC code to handle configN formats in C code
   - Add a warning when an unknown configN attr is found
"

I'm putting '---' in the commit to store the changes for the commit.
The patch ends up with 2 '---' lines, but git drops everything after
the first one. The issue is that
'//lore.kernel.org/all/20220909204509.2169512-1-robh@kernel.org/' is
added to the Cc list.

Rob

Re: b4 v0.10.1 is available

[Konstantin Ryabitsev]

On Tue, Oct 04, 2022 at 02:03:08PM -0500, Rob Herring wrote:
> I found a couple of issues with trailers and send. I'm on the current master.
> 
> In 'b4 trailers', if the patch id doesn't match exactly and it finds
> some trailers, b4 just prints 'No trailer updates found.' which is
> misleading. Can it have a fallback to subject matching or at least
> print when there isn't an exact match and list the trailers found.

Strange, I thought we already did fall back to subject matching when we
couldn't match by patch-id. I'll work to set up a couple of testcases so we
can easily identify such regressions (if that's what it is) in the future.

> It's quite common to either have minor changes (and a judgement call
> on whether tags still apply) or a review that's 'With X fixed,
> Reviewed-by: ...".
> 
> The 2nd issue is with 'b4 send' and seems to have been introduced
> recently. I have a commit msg like this:
> "
> Some commit
> 
> Signed-off-by: ...
> ---
>  v2: https://lore.kernel.org/all/20220909204509.2169512-1-robh@kernel.org/
>    - Rework YACC code to handle configN formats in C code
>    - Add a warning when an unknown configN attr is found
> "
> 
> I'm putting '---' in the commit to store the changes for the commit.
> The patch ends up with 2 '---' lines, but git drops everything after
> the first one. The issue is that
> '//lore.kernel.org/all/20220909204509.2169512-1-robh@kernel.org/' is
> added to the Cc list.

Thank you for the report -- I wasn't expecting to find changelog entries in
the commits, so I'll add that to tests as well and fix it up.

-K

Re: b4 v0.10.1 is available

[Konstantin Ryabitsev]

On Tue, Oct 04, 2022 at 02:03:08PM -0500, Rob Herring wrote:
> I found a couple of issues with trailers and send. I'm on the current master.
> 
> In 'b4 trailers', if the patch id doesn't match exactly and it finds
> some trailers, b4 just prints 'No trailer updates found.' which is
> misleading. Can it have a fallback to subject matching or at least
> print when there isn't an exact match and list the trailers found.
> It's quite common to either have minor changes (and a judgement call
> on whether tags still apply) or a review that's 'With X fixed,
> Reviewed-by: ...".
> 
> The 2nd issue is with 'b4 send' and seems to have been introduced
> recently. I have a commit msg like this:
> "
> Some commit
> 
> Signed-off-by: ...
> ---
>  v2: https://lore.kernel.org/all/20220909204509.2169512-1-robh@kernel.org/
>    - Rework YACC code to handle configN formats in C code
>    - Add a warning when an unknown configN attr is found
> "
> 
> I'm putting '---' in the commit to store the changes for the commit.
> The patch ends up with 2 '---' lines, but git drops everything after
> the first one. The issue is that
> '//lore.kernel.org/all/20220909204509.2169512-1-robh@kernel.org/' is
> added to the Cc list.

Thank you for your report. Both of these should be now fixed in the latest
master and stable-0.10.y.

-K