[<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