tools.linux.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rob Herring" <robh@kernel.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: users@linux.kernel.org, tools@linux.kernel.org
Subject: Re: [kernel.org users] b4 v0.4.0 available with new features
Date: Mon, 4 May 2020 12:09:49 -0500	[thread overview]
Message-ID: <CAL_JsqJ+0Py_XtTojshKPV+o8Y1-Z=pGYJFODDTRVuroLpsJCw@mail.gmail.com> (raw)
In-Reply-To: <20200424170442.ad3b3j5f5vkbcmvb@chatter.i7.local>

On Fri, Apr 24, 2020 at 12:04 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hi, all:
>
> I am happy to release b4 version 0.4.0 that contains a set of
> improvements and new features. To upgrade from pypi, run:

Thanks Konstantin! A couple of requests below.

> pip install --upgrade --user b4
>
> Or you can clone the repository directly:
> git clone https://git.kernel.org/pub/scm/utils/b4/b4.git -b stable-0.4.y b4
>
> You can run ./b4.sh from the repository or set an alias/symlink to that
> wrapper.
>
> # Improvements
>
> - When a series is missing patches, b4 is now able to backfill them from
>   other mailing lists tracked on lore.kernel.org. This feature will be
>   improved when public-inbox is able to collect a thread from across all
>   sources.
> - If both patch and metadata are identical between rerolls (v1 -> v2),
>   b4 will automatically carry over trailers from v1 to v2. This is handy
>   if there is an sob on [PATCH v2 7/15] from a maintainer that is
>   missing from an identical [PATCH v3 7/15]. In my observation, this
>   happens very rarely, though.

This is pretty common actually. At least common enough that I do a
check for this and have a semi-automated reply for it.

I worry that automatically fixing it silently will create yet another
case of tribal knowledge of maintainer practices/requirements for
submitters. Maintainer A using b4 doesn't care if tags are added, but
Maintainer B does care and gets grumpy. We need the tooling to promote
that submitters should add these tags as that is what works in either
case. It would be useful if b4 provided just the check as a separate
command/option for integrating into maintainers tools or maybe
submitter tools like checkpatch.pl.


More generally, as I've started to integrate b4 into my workflow,
there's a couple of useful pieces of functionality already in b4, but
not exposed directly on their own. It would be nice to have both
porcelain and low-level commands.

It would help for scripting if 'mbox' stdout was just the mbox file
name similar to git-format-patch output and send the rest to stderr.
While I have message-id and can construct the mbox name, there can be
some transformation on it.

It would help if the old versions of a series could optionally be
included in the mbox output.

Can the lore search code in get_newest_series be exposed as a command
taking a search string and outputting an mbox? Essentially, what the
lore web interface does with a search box and 'mbox.gz' button (I
tried and gave up doing that with curl).

Rob

  parent reply	other threads:[~2020-05-04 17:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 17:04 b4 v0.4.0 available with new features Konstantin Ryabitsev
2020-04-24 23:35 ` [tools] " Martin K. Petersen
2020-04-27 18:40   ` Konstantin Ryabitsev
2020-04-28  2:12     ` Martin K. Petersen
2020-04-28 15:16       ` Konstantin Ryabitsev
2020-04-29  3:25         ` Martin K. Petersen
2020-04-28 16:03       ` [kernel.org users] " Jason Gunthorpe
2020-05-04 17:09 ` Rob Herring [this message]
2020-05-04 17:17   ` [kernel.org users] " Jason Gunthorpe
2020-05-04 20:09     ` Konstantin Ryabitsev
2020-05-04 23:07       ` Jason Gunthorpe
2020-05-04 20:03   ` Konstantin Ryabitsev
2020-05-04 22:58     ` Jason Gunthorpe
2020-05-04 23:04     ` Rob Herring
2020-05-06 19:23 ` Rob Herring
2020-05-07 20:20   ` Konstantin Ryabitsev
2020-05-12 19:07     ` Rob Herring
2020-06-09 22:24       ` Rob Herring
2020-07-27 14:52         ` Konstantin Ryabitsev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAL_JsqJ+0Py_XtTojshKPV+o8Y1-Z=pGYJFODDTRVuroLpsJCw@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=tools@linux.kernel.org \
    --cc=users@linux.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).