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: <20220128143820.21025a4e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Fri, 28 Jan 2022 14:38:20 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        BlueZ <linux-bluetooth@...r.kernel.org>, netdev@...r.kernel.org
Subject: Re: pull request: bluetooth 2022-01-28

On Fri, 28 Jan 2022 23:30:14 +0100 Marcel Holtmann wrote:
> > Thanks for fixing the warnings! :)
> > 
> > I presume this is for the net-next given the name of your tree, but 
> > a lot of patches here have fixes tags. What's your methodology on
> > separating fixes from new features?
> > 
> > I think it may be worth adjusting the filter there and send more 
> > stuff earlier to Linus's tree. Especially fixes with the right mix 
> > of confidence and impact or pure device ID additions.
> > 
> > To be clear - happy to pull this PR as is, I was meaning to ask about
> > this for a while.  
> 
> we started to add Fixes: tag whenever you can identify a faulty commit or
> can track down the original issue. This way we can later easily go back
> and check. It have to note that a lot of vendor trees cherrypick patches
> and this helps them picking the right ones.

Thumbs up for that!

> I reviewed the list of patches again, and frankly none of them are super
> critical to go to Linus right away. 

My concern is that GregKH will start asking us why we hold onto trivial
fixes like 5201d23cc8e5 until the merge window, I think this merge
window has overflown his patch ID scheme ;) The risk of pushing fixes
in early -rc's should be pretty low. But your call at the end of the
day!

> So if you don’t mind, please pull.

Sure thing, done! :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ