lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zxjg7Cvw0qIzl0v6@sashalap>
Date: Wed, 23 Oct 2024 07:41:32 -0400
From: Sasha Levin <sashal@...nel.org>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: "Darrick J. Wong" <djwong@...nel.org>,
	Kent Overstreet <kent.overstreet@...ux.dev>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, kees@...nel.org, hch@...radead.org,
	broonie@...nel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.12-rc5

On Wed, Oct 23, 2024 at 09:42:59PM +1100, Michael Ellerman wrote:
>Hi Sasha,
>
>This is awesome.
>
>Sasha Levin <sashal@...nel.org> writes:
>> On Tue, Oct 22, 2024 at 01:49:31PM -0700, Darrick J. Wong wrote:
>>>On Tue, Oct 22, 2024 at 03:06:38PM -0400, Sasha Levin wrote:
>>>> other information that would be useful?
>>>
>>>As a maintainer I probably would've found this to be annoying, but with
>>>all my other outside observer / participant hats on, I think it's very
>>>good to have a bot to expose maintainers not following the process.
>>
>> This was my thinking too. Maybe it makes sense for the bot to shut up if
>> things look good (i.e. >N days in stable, everything on the mailing
>> list). Or maybe just a simple "LGTM" or a "Reviewed-by:..."?
>
>I think it has to reply with something, otherwise folks will wonder if
>the bot has broken or missed their pull request.
>
>But if all commits were in in linux-next and posted to a list, then the
>only content is the "Days in linux-next" histogram, which is not that long
>and is useful information IMHO.
>
>It would be nice if you could trim the tail of the histogram below the
>last populated row, that would make it more concise.

Makes sense, I'll do that.

>For fixes pulls it is sometimes legitimate for commits not to have been
>in linux-next. But I think it's still good for the bot to highlight
>those, ideally fixes that miss linux-next are either very urgent or
>minor.

Right, and Linus said he's okay with those. This is not a "shame" list
but rather "look a little closer" list.

>>>> Commits that weren't found on lore.kernel.org/all:
>>>> --------------------
>>>> e04ee8608914d bcachefs: Mark more errors as AUTOFIX
>>>> f0d3302073e60 bcachefs: Workaround for kvmalloc() not supporting > INT_MAX allocations
>>>> bc6d2d10418e1 bcachefs: fsck: Improve hash_check_key()
>>>> dc96656b20eb6 bcachefs: bch2_hash_set_or_get_in_snapshot()
>>>> 15a3836c8ed7b bcachefs: Repair mismatches in inode hash seed, type
>>>> d8e879377ffb3 bcachefs: Add hash seed, type to inode_to_text()
>>>> 78cf0ae636a55 bcachefs: INODE_STR_HASH() for bch_inode_unpacked
>>>> b96f8cd3870a1 bcachefs: Run in-kernel offline fsck without ratelimit errors
>>>> 4007bbb203a0c bcachefS: ec: fix data type on stripe deletion
>
>Are you searching by message id, or subject? I sometimes edit subjects
>when applying patches, so a subject search could miss some.

Both, and also by patch id, so if you just change the subject it should
still be okay.

We'll see when you send your next PR :)

-- 
Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ