* Re: New version of lore available for preview
2021-09-09 13:32 ` Lee Jones
@ 2021-09-09 13:38 ` Konstantin Ryabitsev
2021-09-09 13:45 ` Lee Jones
2021-09-09 13:43 ` Greg KH
` (2 subsequent siblings)
3 siblings, 1 reply; 37+ messages in thread
From: Konstantin Ryabitsev @ 2021-09-09 13:38 UTC (permalink / raw)
To: Lee Jones; +Cc: Steven Rostedt, Masahiro Yamada, Jason Gunthorpe, users, tools
On Thu, Sep 09, 2021 at 02:32:25PM +0100, Lee Jones wrote:
> In my current implementation, I have pwclient pull down the patch,
> apply my SoB and apply the it, all in one foul swoop:
>
> pwclient git-am -p ${project} -3 -s ${pwid}
>
> Does b4 provide this functionality too, or do I have to script around
> it? How have other's chosen to automatically apply the downloaded
> mboxes?
b4 am -3 -s -o- msgid | git am
-K
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: New version of lore available for preview
2021-09-09 13:38 ` Konstantin Ryabitsev
@ 2021-09-09 13:45 ` Lee Jones
2021-09-09 14:39 ` Konstantin Ryabitsev
2021-09-09 14:51 ` Alexandre Belloni
0 siblings, 2 replies; 37+ messages in thread
From: Lee Jones @ 2021-09-09 13:45 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Steven Rostedt, Masahiro Yamada, Jason Gunthorpe, users, tools
On Thu, 09 Sep 2021, Konstantin Ryabitsev wrote:
> On Thu, Sep 09, 2021 at 02:32:25PM +0100, Lee Jones wrote:
> > In my current implementation, I have pwclient pull down the patch,
> > apply my SoB and apply the it, all in one foul swoop:
> >
> > pwclient git-am -p ${project} -3 -s ${pwid}
> >
> > Does b4 provide this functionality too, or do I have to script around
> > it? How have other's chosen to automatically apply the downloaded
> > mboxes?
>
> b4 am -3 -s -o- msgid | git am
Ah yes, piping to stdout and straight into Git works great.
And with "-P _", it does exactly what I want.
Thanks for your quick response Konstantin.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: New version of lore available for preview
2021-09-09 13:45 ` Lee Jones
@ 2021-09-09 14:39 ` Konstantin Ryabitsev
2021-09-09 15:24 ` James Bottomley
2021-09-09 14:51 ` Alexandre Belloni
1 sibling, 1 reply; 37+ messages in thread
From: Konstantin Ryabitsev @ 2021-09-09 14:39 UTC (permalink / raw)
To: Lee Jones; +Cc: Steven Rostedt, Masahiro Yamada, Jason Gunthorpe, users, tools
On Thu, Sep 09, 2021 at 02:45:53PM +0100, Lee Jones wrote:
> > b4 am -3 -s -o- msgid | git am
>
> Ah yes, piping to stdout and straight into Git works great.
>
> And with "-P _", it does exactly what I want.
>
> Thanks for your quick response Konstantin.
No worries, and like I said -- if you actually need patchwork for tracking
state, then we'll be adding a way to create search-based projects in the near
future.
-K
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-09 14:39 ` Konstantin Ryabitsev
@ 2021-09-09 15:24 ` James Bottomley
2021-09-09 16:17 ` Konstantin Ryabitsev
0 siblings, 1 reply; 37+ messages in thread
From: James Bottomley @ 2021-09-09 15:24 UTC (permalink / raw)
To: Konstantin Ryabitsev, Lee Jones
Cc: Steven Rostedt, Masahiro Yamada, Jason Gunthorpe, users, tools
On Thu, 2021-09-09 at 10:39 -0400, Konstantin Ryabitsev wrote:
> On Thu, Sep 09, 2021 at 02:45:53PM +0100, Lee Jones wrote:
> > > b4 am -3 -s -o- msgid | git am
> >
> > Ah yes, piping to stdout and straight into Git works great.
> >
> > And with "-P _", it does exactly what I want.
> >
> > Thanks for your quick response Konstantin.
>
> No worries, and like I said -- if you actually need patchwork for
> tracking state, then we'll be adding a way to create search-based
> projects in the near future.
I thought public inbox had a mechanism for tracking local state: the
most pressing being whether you've read the message or not when you use
imap backed by public inbox. Can't this local tracking be extended to
do other useful things patchwork previously did?
James
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-09 15:24 ` James Bottomley
@ 2021-09-09 16:17 ` Konstantin Ryabitsev
0 siblings, 0 replies; 37+ messages in thread
From: Konstantin Ryabitsev @ 2021-09-09 16:17 UTC (permalink / raw)
To: James Bottomley
Cc: Lee Jones, Steven Rostedt, Masahiro Yamada, Jason Gunthorpe,
users, tools
On Thu, Sep 09, 2021 at 08:24:28AM -0700, James Bottomley wrote:
> > No worries, and like I said -- if you actually need patchwork for
> > tracking state, then we'll be adding a way to create search-based
> > projects in the near future.
>
> I thought public inbox had a mechanism for tracking local state: the
> most pressing being whether you've read the message or not when you use
> imap backed by public inbox. Can't this local tracking be extended to
> do other useful things patchwork previously did?
Pretty sure that's not currently the case -- public-inbox-imapd provides
readonly access and does no state tracking.
That's not to be confused with the new "lei" command provided by public-inbox
that can collect threads from local and remote sources and make them available
either as local maildirs or upload them to an imap folder. The "lei" interface
is still being finalized, so I don't want to over-advertise it yet until the
dust settles. Once completed, it should allow anyone to "receive" mail based
on custom queries straight from lore or other public-inbox or imap sources.
-K
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-09 13:45 ` Lee Jones
2021-09-09 14:39 ` Konstantin Ryabitsev
@ 2021-09-09 14:51 ` Alexandre Belloni
2021-09-09 15:00 ` Konstantin Ryabitsev
1 sibling, 1 reply; 37+ messages in thread
From: Alexandre Belloni @ 2021-09-09 14:51 UTC (permalink / raw)
To: Lee Jones
Cc: Konstantin Ryabitsev, Steven Rostedt, Masahiro Yamada,
Jason Gunthorpe, users, tools
On 09/09/2021 14:45:53+0100, Lee Jones wrote:
> On Thu, 09 Sep 2021, Konstantin Ryabitsev wrote:
>
> > On Thu, Sep 09, 2021 at 02:32:25PM +0100, Lee Jones wrote:
> > > In my current implementation, I have pwclient pull down the patch,
> > > apply my SoB and apply the it, all in one foul swoop:
> > >
> > > pwclient git-am -p ${project} -3 -s ${pwid}
> > >
> > > Does b4 provide this functionality too, or do I have to script around
> > > it? How have other's chosen to automatically apply the downloaded
> > > mboxes?
> >
> > b4 am -3 -s -o- msgid | git am
>
> Ah yes, piping to stdout and straight into Git works great.
>
> And with "-P _", it does exactly what I want.
>
I did use the stdout piping to git am until I have seen someone on a
mailing list adding this to .gitconfig
[alias]
b4am = "!sh -c 'b4 am -ctsl -o- $1 | git am' -"
b4am1 = "!sh -c 'b4 am -ctsl -o- -P_ $1 | git am' -"
and then you can directly do git b4am <msg-id>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: New version of lore available for preview
2021-09-09 14:51 ` Alexandre Belloni
@ 2021-09-09 15:00 ` Konstantin Ryabitsev
0 siblings, 0 replies; 37+ messages in thread
From: Konstantin Ryabitsev @ 2021-09-09 15:00 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Lee Jones, Steven Rostedt, Masahiro Yamada, Jason Gunthorpe,
users, tools
On Thu, Sep 09, 2021 at 04:51:14PM +0200, Alexandre Belloni wrote:
> I did use the stdout piping to git am until I have seen someone on a
> mailing list adding this to .gitconfig
>
> [alias]
> b4am = "!sh -c 'b4 am -ctsl -o- $1 | git am' -"
> b4am1 = "!sh -c 'b4 am -ctsl -o- -P_ $1 | git am' -"
>
> and then you can directly do git b4am <msg-id>
I intend to add a command to just apply the series directly if all the
prechecks pass:
- attestation is good
- applies cleanly
- no trailer warnings
The fact that folks are writing such aliases tells me that this is needed and
I should stop avoiding modifying the working tree.
-K
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-09 13:32 ` Lee Jones
2021-09-09 13:38 ` Konstantin Ryabitsev
@ 2021-09-09 13:43 ` Greg KH
2021-09-09 13:54 ` Lee Jones
2021-09-10 16:07 ` Bjorn Andersson
2021-09-09 13:55 ` Steven Rostedt
2021-09-09 14:51 ` Peter Zijlstra
3 siblings, 2 replies; 37+ messages in thread
From: Greg KH @ 2021-09-09 13:43 UTC (permalink / raw)
To: Lee Jones
Cc: Steven Rostedt, Konstantin Ryabitsev, Masahiro Yamada,
Jason Gunthorpe, users, tools
On Thu, Sep 09, 2021 at 02:32:25PM +0100, Lee Jones wrote:
> On Thu, 09 Sep 2021, Steven Rostedt wrote:
> > On Wed, 8 Sep 2021 14:37:46 -0400
> > Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> >
> > > > Can we represent LKML on Patchwork as a reasonable alternative?
> > >
> > > No. That said, what I'm currently working on is a way to provide query-defined
> > > public-inbox sources. If you can define what kind of patches you are
> > > interested in as a lore.kernel.org query, we can save that search and feed
> > > *that* into patchwork. So, instead of feeding all of LKML into patchwork just
> > > for the few patches you're interested in, we can just feed the subset of
> > > patches that you actually want.
> >
> > This is basically what I have done locally. I set up a local instance of
> > patchwork. Added a procmail filter to copy all my emails with "PATCH" in the
> > subject into its own folder. Then I have a cron job that runs the following
> > script to add "List-ID: <rostedt.inbox.com>" to these emails, as my local
> > patchwork "listens" to the "mailing list" called "rostedt.inbox.com". And
> > then send them off to my local patchwork instance.
> >
> > #!/usr/bin/perl -w
> >
> > my $state = "none";
> > my $patch = 0;
> >
> > while (<>) {
> > if (/^From /) {
> > $state = "head";
> > $patch = 0;
> > } elsif ($state eq "head") {
> > if (/^\s*$/) {
> > print "List-ID: <rostedt.inbox.com>\n" if ($patch);
> > $state = "body";
> > } else {
> > if (/list-id/i) {
> > next;
> > } elsif (/^Subject.*patch/i) {
> > $patch = 1;
> > }
> > }
> > }
> > print;
> > }
> >
> >
> > This works great for me, but I can imagine if people have their own public
> > inboxes, where we can just create a patchwork instance that feeds off of
> > these inboxes, I believe you will get the same functionality that I have.
> >
> > Note, I also have filters to read patches that have "[for-next]" and
> > "[for-linus]" which converts the patches in patchwork from "New" to "Under
> > Review". Then I have a subscription to all commits that go into Linus's
> > tree, and I process all of them to go through and "Approve" any patch that
> > it finds.
> >
> > I still would love a way to download patchwork offline, where it loads
> > locally all pending patches, and lets you review / apply them locally
> > without needing to be connected online, as this would be useful during
> > flights. Then when you land, you can upload your changes.
>
> Well, as beautifully inefficient as that all sounds, it might be
> slightly less time consuming if I just succumb to peer pressure and
> switch pwclient out for b4.
>
> Thankfully, my use-case is much simpler than Steven's.
>
> In my current implementation, I have pwclient pull down the patch,
> apply my SoB and apply the it, all in one foul swoop:
>
> pwclient git-am -p ${project} -3 -s ${pwid}
>
> Does b4 provide this functionality too, or do I have to script around
> it? How have other's chosen to automatically apply the downloaded
> mboxes?
I do it from my mail client by piping the message to this:
b4 am -t -o - | git am -s
which will download the whole series of patches, and acks and
reviewed-by and apply them, and then apply them with git.
I'm sure your email client can do much the same thing.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: New version of lore available for preview
2021-09-09 13:43 ` Greg KH
@ 2021-09-09 13:54 ` Lee Jones
2021-09-09 13:56 ` Mark Brown
2021-09-10 16:07 ` Bjorn Andersson
1 sibling, 1 reply; 37+ messages in thread
From: Lee Jones @ 2021-09-09 13:54 UTC (permalink / raw)
To: Greg KH
Cc: Steven Rostedt, Konstantin Ryabitsev, Masahiro Yamada,
Jason Gunthorpe, users, tools
On Thu, 09 Sep 2021, Greg KH wrote:
> On Thu, Sep 09, 2021 at 02:32:25PM +0100, Lee Jones wrote:
> > On Thu, 09 Sep 2021, Steven Rostedt wrote:
> > > On Wed, 8 Sep 2021 14:37:46 -0400
> > > Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> > >
> > > > > Can we represent LKML on Patchwork as a reasonable alternative?
> > > >
> > > > No. That said, what I'm currently working on is a way to provide query-defined
> > > > public-inbox sources. If you can define what kind of patches you are
> > > > interested in as a lore.kernel.org query, we can save that search and feed
> > > > *that* into patchwork. So, instead of feeding all of LKML into patchwork just
> > > > for the few patches you're interested in, we can just feed the subset of
> > > > patches that you actually want.
> > >
> > > This is basically what I have done locally. I set up a local instance of
> > > patchwork. Added a procmail filter to copy all my emails with "PATCH" in the
> > > subject into its own folder. Then I have a cron job that runs the following
> > > script to add "List-ID: <rostedt.inbox.com>" to these emails, as my local
> > > patchwork "listens" to the "mailing list" called "rostedt.inbox.com". And
> > > then send them off to my local patchwork instance.
> > >
> > > #!/usr/bin/perl -w
> > >
> > > my $state = "none";
> > > my $patch = 0;
> > >
> > > while (<>) {
> > > if (/^From /) {
> > > $state = "head";
> > > $patch = 0;
> > > } elsif ($state eq "head") {
> > > if (/^\s*$/) {
> > > print "List-ID: <rostedt.inbox.com>\n" if ($patch);
> > > $state = "body";
> > > } else {
> > > if (/list-id/i) {
> > > next;
> > > } elsif (/^Subject.*patch/i) {
> > > $patch = 1;
> > > }
> > > }
> > > }
> > > print;
> > > }
> > >
> > >
> > > This works great for me, but I can imagine if people have their own public
> > > inboxes, where we can just create a patchwork instance that feeds off of
> > > these inboxes, I believe you will get the same functionality that I have.
> > >
> > > Note, I also have filters to read patches that have "[for-next]" and
> > > "[for-linus]" which converts the patches in patchwork from "New" to "Under
> > > Review". Then I have a subscription to all commits that go into Linus's
> > > tree, and I process all of them to go through and "Approve" any patch that
> > > it finds.
> > >
> > > I still would love a way to download patchwork offline, where it loads
> > > locally all pending patches, and lets you review / apply them locally
> > > without needing to be connected online, as this would be useful during
> > > flights. Then when you land, you can upload your changes.
> >
> > Well, as beautifully inefficient as that all sounds, it might be
> > slightly less time consuming if I just succumb to peer pressure and
> > switch pwclient out for b4.
> >
> > Thankfully, my use-case is much simpler than Steven's.
> >
> > In my current implementation, I have pwclient pull down the patch,
> > apply my SoB and apply the it, all in one foul swoop:
> >
> > pwclient git-am -p ${project} -3 -s ${pwid}
> >
> > Does b4 provide this functionality too, or do I have to script around
> > it? How have other's chosen to automatically apply the downloaded
> > mboxes?
>
> I do it from my mail client by piping the message to this:
> b4 am -t -o - | git am -s
Not sure what -t does:
Apply trailers sent to the cover letter to all patches
> which will download the whole series of patches, and acks and
> reviewed-by and apply them, and then apply them with git.
>
> I'm sure your email client can do much the same thing.
Right, but I don't want it to do that.
I operate using worktrees and have different Mutt keys apply patches
where required. It's also very unusual for me to apply wholes sets of
patches, thus plucking patches one at a time make more sense as part
of my flow.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: New version of lore available for preview
2021-09-09 13:54 ` Lee Jones
@ 2021-09-09 13:56 ` Mark Brown
2021-09-09 14:05 ` Lee Jones
0 siblings, 1 reply; 37+ messages in thread
From: Mark Brown @ 2021-09-09 13:56 UTC (permalink / raw)
To: Lee Jones
Cc: Greg KH, Steven Rostedt, Konstantin Ryabitsev, Masahiro Yamada,
Jason Gunthorpe, users, tools
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
On Thu, Sep 09, 2021 at 02:54:02PM +0100, Lee Jones wrote:
> On Thu, 09 Sep 2021, Greg KH wrote:
> > I do it from my mail client by piping the message to this:
> > b4 am -t -o - | git am -s
> Not sure what -t does:
> Apply trailers sent to the cover letter to all patches
If someone sends an Acked-by or whatever in reply to the cover letter b4
will pick that up for all patches in the series.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-09 13:56 ` Mark Brown
@ 2021-09-09 14:05 ` Lee Jones
0 siblings, 0 replies; 37+ messages in thread
From: Lee Jones @ 2021-09-09 14:05 UTC (permalink / raw)
To: Mark Brown
Cc: Greg KH, Steven Rostedt, Konstantin Ryabitsev, Masahiro Yamada,
Jason Gunthorpe, users, tools
On Thu, 09 Sep 2021, Mark Brown wrote:
> On Thu, Sep 09, 2021 at 02:54:02PM +0100, Lee Jones wrote:
> > On Thu, 09 Sep 2021, Greg KH wrote:
>
> > > I do it from my mail client by piping the message to this:
> > > b4 am -t -o - | git am -s
>
> > Not sure what -t does:
>
> > Apply trailers sent to the cover letter to all patches
>
> If someone sends an Acked-by or whatever in reply to the cover letter b4
> will pick that up for all patches in the series.
Got it. Thanks Mark.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-09 13:43 ` Greg KH
2021-09-09 13:54 ` Lee Jones
@ 2021-09-10 16:07 ` Bjorn Andersson
2021-09-10 16:12 ` Mark Brown
1 sibling, 1 reply; 37+ messages in thread
From: Bjorn Andersson @ 2021-09-10 16:07 UTC (permalink / raw)
To: Greg KH
Cc: Lee Jones, Steven Rostedt, Konstantin Ryabitsev, Masahiro Yamada,
Jason Gunthorpe, users, tools
On Thu 09 Sep 06:43 PDT 2021, Greg KH wrote:
> On Thu, Sep 09, 2021 at 02:32:25PM +0100, Lee Jones wrote:
> > On Thu, 09 Sep 2021, Steven Rostedt wrote:
> > > On Wed, 8 Sep 2021 14:37:46 -0400
> > > Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> > >
> > > > > Can we represent LKML on Patchwork as a reasonable alternative?
> > > >
> > > > No. That said, what I'm currently working on is a way to provide query-defined
> > > > public-inbox sources. If you can define what kind of patches you are
> > > > interested in as a lore.kernel.org query, we can save that search and feed
> > > > *that* into patchwork. So, instead of feeding all of LKML into patchwork just
> > > > for the few patches you're interested in, we can just feed the subset of
> > > > patches that you actually want.
> > >
> > > This is basically what I have done locally. I set up a local instance of
> > > patchwork. Added a procmail filter to copy all my emails with "PATCH" in the
> > > subject into its own folder. Then I have a cron job that runs the following
> > > script to add "List-ID: <rostedt.inbox.com>" to these emails, as my local
> > > patchwork "listens" to the "mailing list" called "rostedt.inbox.com". And
> > > then send them off to my local patchwork instance.
> > >
> > > #!/usr/bin/perl -w
> > >
> > > my $state = "none";
> > > my $patch = 0;
> > >
> > > while (<>) {
> > > if (/^From /) {
> > > $state = "head";
> > > $patch = 0;
> > > } elsif ($state eq "head") {
> > > if (/^\s*$/) {
> > > print "List-ID: <rostedt.inbox.com>\n" if ($patch);
> > > $state = "body";
> > > } else {
> > > if (/list-id/i) {
> > > next;
> > > } elsif (/^Subject.*patch/i) {
> > > $patch = 1;
> > > }
> > > }
> > > }
> > > print;
> > > }
> > >
> > >
> > > This works great for me, but I can imagine if people have their own public
> > > inboxes, where we can just create a patchwork instance that feeds off of
> > > these inboxes, I believe you will get the same functionality that I have.
> > >
> > > Note, I also have filters to read patches that have "[for-next]" and
> > > "[for-linus]" which converts the patches in patchwork from "New" to "Under
> > > Review". Then I have a subscription to all commits that go into Linus's
> > > tree, and I process all of them to go through and "Approve" any patch that
> > > it finds.
> > >
> > > I still would love a way to download patchwork offline, where it loads
> > > locally all pending patches, and lets you review / apply them locally
> > > without needing to be connected online, as this would be useful during
> > > flights. Then when you land, you can upload your changes.
> >
> > Well, as beautifully inefficient as that all sounds, it might be
> > slightly less time consuming if I just succumb to peer pressure and
> > switch pwclient out for b4.
> >
> > Thankfully, my use-case is much simpler than Steven's.
> >
> > In my current implementation, I have pwclient pull down the patch,
> > apply my SoB and apply the it, all in one foul swoop:
> >
> > pwclient git-am -p ${project} -3 -s ${pwid}
> >
> > Does b4 provide this functionality too, or do I have to script around
> > it? How have other's chosen to automatically apply the downloaded
> > mboxes?
>
> I do it from my mail client by piping the message to this:
> b4 am -t -o - | git am -s
>
The integration directly in the mail client is a really nice trick.
> which will download the whole series of patches, and acks and
> reviewed-by and apply them, and then apply them with git.
>
Unfortunately when it comes to hardware platform enablement we do get a
lot of series that spans across multiple subsystems and we've seen
several examples where applying the whole series causes merge conflicts
down the road.
As this is very common in my inbox I've yet to migrate to b4.
Is this (pick a single msg) supported in b4, am I just missing something
in the documentation?
Regards,
Bjorn
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: New version of lore available for preview
2021-09-10 16:07 ` Bjorn Andersson
@ 2021-09-10 16:12 ` Mark Brown
2021-09-10 17:21 ` Peter Zijlstra
0 siblings, 1 reply; 37+ messages in thread
From: Mark Brown @ 2021-09-10 16:12 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Greg KH, Lee Jones, Steven Rostedt, Konstantin Ryabitsev,
Masahiro Yamada, Jason Gunthorpe, users, tools
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
On Fri, Sep 10, 2021 at 09:07:52AM -0700, Bjorn Andersson wrote:
> Is this (pick a single msg) supported in b4, am I just missing something
> in the documentation?
You can pick a subset of patches but only by specifying the patch
numbers on the command line - I do this outside the mail client as part
of saying which trees and branches the patches are going to.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-10 16:12 ` Mark Brown
@ 2021-09-10 17:21 ` Peter Zijlstra
0 siblings, 0 replies; 37+ messages in thread
From: Peter Zijlstra @ 2021-09-10 17:21 UTC (permalink / raw)
To: Mark Brown
Cc: Bjorn Andersson, Greg KH, Lee Jones, Steven Rostedt,
Konstantin Ryabitsev, Masahiro Yamada, Jason Gunthorpe, users,
tools
On Fri, Sep 10, 2021 at 05:12:04PM +0100, Mark Brown wrote:
> On Fri, Sep 10, 2021 at 09:07:52AM -0700, Bjorn Andersson wrote:
>
> > Is this (pick a single msg) supported in b4, am I just missing something
> > in the documentation?
>
> You can pick a subset of patches but only by specifying the patch
> numbers on the command line - I do this outside the mail client as part
> of saying which trees and branches the patches are going to.
See my earlier email to Lee, you can have mutt pipe in whichever
messages you want to apply (and their replies) and have b4 do it's magic
on them.
I typically start by selecting the whole thread using ESC-t and then
unselecting the patches I want to hold back, but whatever works for you
best...
basically you have to use: "b4 -m -" (in addition to the other flags) in
order for it to accept a local mbox on stdin, instead of scraping the
web.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-09 13:32 ` Lee Jones
2021-09-09 13:38 ` Konstantin Ryabitsev
2021-09-09 13:43 ` Greg KH
@ 2021-09-09 13:55 ` Steven Rostedt
2021-09-09 14:04 ` Lee Jones
2021-09-09 14:51 ` Peter Zijlstra
3 siblings, 1 reply; 37+ messages in thread
From: Steven Rostedt @ 2021-09-09 13:55 UTC (permalink / raw)
To: Lee Jones
Cc: Konstantin Ryabitsev, Masahiro Yamada, Jason Gunthorpe, users, tools
On Thu, 9 Sep 2021 14:32:25 +0100
Lee Jones <lee.jones@linaro.org> wrote:
> Well, as beautifully inefficient as that all sounds, it might be
> slightly less time consuming if I just succumb to peer pressure and
> switch pwclient out for b4.
The old "Show them an even more painful alternative to make the current
solution seem good" trick.
>
> Thankfully, my use-case is much simpler than Steven's.
Of course, my solution came before b4 was even thought of (I even mentioned
this solution in the kernel summit discussion that started the path to b4).
The one thing I need that b4 doesn't give me, is a place outside of email
to keep track of the state of patches. I've failed in all my attempts at
using email folders to do this. What I love about patchwork is that I can
keep the patches at various states.
New - I just received it and need to look at it / test it.
Under review - They have been tested, just need to be pushed to upstream.
Accepted - they have been accepted.
I also created other states for topics, like "Real Time", "Scheduler",
"RCU", etc, so that I can go back if I have time (which currently I never
do), and look at these patches.
I also use the "delegate" option to assign patches to myself that are high
in priority.
I tried doing this with email folders, and even a git repo, but because I
use email and git for so much else, it still gets lost in the noise. I like
patchwork because its web based, and I have a window up all the time that
shows me what patches I need to work on next.
The pulling into git is actually one of the trivial parts of the process.
-- Steve
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-09 13:55 ` Steven Rostedt
@ 2021-09-09 14:04 ` Lee Jones
0 siblings, 0 replies; 37+ messages in thread
From: Lee Jones @ 2021-09-09 14:04 UTC (permalink / raw)
To: Steven Rostedt
Cc: Konstantin Ryabitsev, Masahiro Yamada, Jason Gunthorpe, users, tools
On Thu, 09 Sep 2021, Steven Rostedt wrote:
> On Thu, 9 Sep 2021 14:32:25 +0100
> Lee Jones <lee.jones@linaro.org> wrote:
>
> > Well, as beautifully inefficient as that all sounds, it might be
> > slightly less time consuming if I just succumb to peer pressure and
> > switch pwclient out for b4.
>
> The old "Show them an even more painful alternative to make the current
> solution seem good" trick.
Works every time! :)
> > Thankfully, my use-case is much simpler than Steven's.
>
> Of course, my solution came before b4 was even thought of (I even mentioned
> this solution in the kernel summit discussion that started the path to b4).
>
> The one thing I need that b4 doesn't give me, is a place outside of email
> to keep track of the state of patches. I've failed in all my attempts at
> using email folders to do this. What I love about patchwork is that I can
> keep the patches at various states.
>
> New - I just received it and need to look at it / test it.
>
> Under review - They have been tested, just need to be pushed to upstream.
>
> Accepted - they have been accepted.
>
> I also created other states for topics, like "Real Time", "Scheduler",
> "RCU", etc, so that I can go back if I have time (which currently I never
> do), and look at these patches.
>
> I also use the "delegate" option to assign patches to myself that are high
> in priority.
>
> I tried doing this with email folders, and even a git repo, but because I
> use email and git for so much else, it still gets lost in the noise. I like
> patchwork because its web based, and I have a window up all the time that
> shows me what patches I need to work on next.
>
> The pulling into git is actually one of the trivial parts of the process.
I like to keep my setup as KISS as possible.
Fortunately, in terms of upstream reviews I've managed to whittle
patches down into 3 states;
- unread
- does not need review
- needs review
The latter is represented with Mutt's 'flag-message' functionality.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: New version of lore available for preview
2021-09-09 13:32 ` Lee Jones
` (2 preceding siblings ...)
2021-09-09 13:55 ` Steven Rostedt
@ 2021-09-09 14:51 ` Peter Zijlstra
2021-09-10 6:10 ` Lee Jones
3 siblings, 1 reply; 37+ messages in thread
From: Peter Zijlstra @ 2021-09-09 14:51 UTC (permalink / raw)
To: Lee Jones
Cc: Steven Rostedt, Konstantin Ryabitsev, Masahiro Yamada,
Jason Gunthorpe, users, tools
On Thu, Sep 09, 2021 at 02:32:25PM +0100, Lee Jones wrote:
> Does b4 provide this functionality too, or do I have to script around
> it? How have other's chosen to automatically apply the downloaded
> mboxes?
My .muttrc has:
macro index B "<tag-prefix><pipe-entry>formail -ds | b4 am -slt -m - -o - | formail -s ~/mutt/mutt-pipe.sh<enter><untag-pattern>~T<enter>"
(which relies on that same muttrc having: set pipe_split=no)
which allows me to tag a (partial) thread using ESC-t (or otherwise) and
apply the resulting lot (with folding of tags and adding signature and
all the goodness) to my quilt series (as done by my mutt-pipe.sh
script).
The initial "formail -ds" is required because mutt pipe output isn't
exactly the mbox format b4 expects and formail basically reformats it,
it's mbox in mbox out. Then b4 takes the mbox, folds tags and generates
a reduced mbox with only patches; formail then splits it and my old and
trusty mutt-pipe.sh frobs it into quilt one at a time.
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: New version of lore available for preview
2021-09-09 14:51 ` Peter Zijlstra
@ 2021-09-10 6:10 ` Lee Jones
0 siblings, 0 replies; 37+ messages in thread
From: Lee Jones @ 2021-09-10 6:10 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Steven Rostedt, Konstantin Ryabitsev, Masahiro Yamada,
Jason Gunthorpe, users, tools
On Thu, 09 Sep 2021, Peter Zijlstra wrote:
> On Thu, Sep 09, 2021 at 02:32:25PM +0100, Lee Jones wrote:
> > Does b4 provide this functionality too, or do I have to script around
> > it? How have other's chosen to automatically apply the downloaded
> > mboxes?
>
> My .muttrc has:
>
> macro index B "<tag-prefix><pipe-entry>formail -ds | b4 am -slt -m - -o - | formail -s ~/mutt/mutt-pipe.sh<enter><untag-pattern>~T<enter>"
>
> (which relies on that same muttrc having: set pipe_split=no)
>
> which allows me to tag a (partial) thread using ESC-t (or otherwise) and
> apply the resulting lot (with folding of tags and adding signature and
> all the goodness) to my quilt series (as done by my mutt-pipe.sh
> script).
>
> The initial "formail -ds" is required because mutt pipe output isn't
> exactly the mbox format b4 expects and formail basically reformats it,
> it's mbox in mbox out. Then b4 takes the mbox, folds tags and generates
> a reduced mbox with only patches; formail then splits it and my old and
> trusty mutt-pipe.sh frobs it into quilt one at a time.
This might well be handy.
I'll probably look into this when I have a need i.e. when I come
across my first multi-patch merge where there has been subsequent
reviews (trailers) added to the thread.
Thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 37+ messages in thread