Linux maintainer tooling and workflows
 help / color / Atom feed
* b4 ty not remembering fetched patches
@ 2020-05-15 18:19 Mark Brown
  2020-05-15 18:36 ` Konstantin Ryabitsev
  0 siblings, 1 reply; 3+ messages in thread
From: Mark Brown @ 2020-05-15 18:19 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: tools


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

Hi Konstantin,

When I run 

	b4 am -t 20200515104758.6934-1-Sergey.Semin@baikalelectronics.ru

a mailbox is generated (incomplete due to issues with vger spam
filtering) but the fetched patches are not recorded in the b4 ty
database (as showing by b4 ty -l).  This happens even if only patches
that are present on the list are requested on the command line.

Thanks,
Mark

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: b4 ty not remembering fetched patches
  2020-05-15 18:19 b4 ty not remembering fetched patches Mark Brown
@ 2020-05-15 18:36 ` Konstantin Ryabitsev
  2020-05-15 19:26   ` Mark Brown
  0 siblings, 1 reply; 3+ messages in thread
From: Konstantin Ryabitsev @ 2020-05-15 18:36 UTC (permalink / raw)
  To: Mark Brown; +Cc: tools

On Fri, May 15, 2020 at 07:19:18PM +0100, Mark Brown wrote:
> Hi Konstantin,
> 
> When I run 
> 
> 	b4 am -t 20200515104758.6934-1-Sergey.Semin@baikalelectronics.ru
> 
> a mailbox is generated (incomplete due to issues with vger spam
> filtering) but the fetched patches are not recorded in the b4 ty
> database (as showing by b4 ty -l).  This happens even if only patches
> that are present on the list are requested on the command line.

Right, this was intentional due to trying to be over-cautious. If we 
don't have the complete thread, then we probably shouldn't be tracking 
if this incomplete thread was applied or not -- at least that was my 
thinking. What is your thoughts on that?

Of course, if we're specifically selecting a subset of that thread, we 
shouldn't be applying that logic. I'll see if I can add that caveat in.

Thanks,
-K

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: b4 ty not remembering fetched patches
  2020-05-15 18:36 ` Konstantin Ryabitsev
@ 2020-05-15 19:26   ` Mark Brown
  0 siblings, 0 replies; 3+ messages in thread
From: Mark Brown @ 2020-05-15 19:26 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: tools


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

On Fri, May 15, 2020 at 02:36:02PM -0400, Konstantin Ryabitsev wrote:
> On Fri, May 15, 2020 at 07:19:18PM +0100, Mark Brown wrote:

> > a mailbox is generated (incomplete due to issues with vger spam
> > filtering) but the fetched patches are not recorded in the b4 ty
> > database (as showing by b4 ty -l).  This happens even if only patches
> > that are present on the list are requested on the command line.

> Right, this was intentional due to trying to be over-cautious. If we 
> don't have the complete thread, then we probably shouldn't be tracking 
> if this incomplete thread was applied or not -- at least that was my 
> thinking. What is your thoughts on that?

I think that's a sensible decision and wasn't particularly surprised by
that bit of it.  In fact what might be handy would be an option to not
output the partial mailbox if we can't find some of the patches - that'd
help spot problems early on in the process.

> Of course, if we're specifically selecting a subset of that thread, we 
> shouldn't be applying that logic. I'll see if I can add that caveat in.

Right, I'd have expected it to only apply to whatever was explicitly
asked for.

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-15 18:19 b4 ty not remembering fetched patches Mark Brown
2020-05-15 18:36 ` Konstantin Ryabitsev
2020-05-15 19:26   ` Mark Brown

Linux maintainer tooling and workflows

Archives are clonable:
	git clone --mirror https://lore.kernel.org/tools/0 tools/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 tools tools/ https://lore.kernel.org/tools \
		tools@linux.kernel.org
	public-inbox-index tools

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.linux.tools


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git