[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20211005075133.38a31995@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Tue, 5 Oct 2021 07:51:33 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc: David Miller <davem@...emloft.net>,
"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
"open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>
Subject: Re: pull request: bluetooth 2021-10-04
On Mon, 4 Oct 2021 20:47:35 -0700 Luiz Augusto von Dentz wrote:
> On Mon, Oct 4, 2021 at 6:22 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > On Mon, 4 Oct 2021 15:21:46 -0700 Luiz Augusto von Dentz wrote:
> > > bluetooth-next pull request for net-next:
> > >
> > > - Add support for MediaTek MT7922 and MT7921
> > > - Add support for TP-Link UB500
> > > - Enable support for AOSP extention in Qualcomm WCN399x and Realtek
> > > 8822C/8852A.
> > > - Add initial support for link quality and audio/codec offload.
> > > - Rework of sockets sendmsg to avoid locking issues.
> > > - Add vhci suspend/resume emulation.
> >
> > Now it's flipped, it's complaining about Luiz being the committer
> > but there's only a sign off from Marcel :(
>
> I did have both sign-off, or are you saying Ive now become the
> committer of other patches as well? Which means whoever rebases the
> tree has to sign-off the entire set as well, I guess other trees does
> better with this because they don't have multiple committer but once
> you have that it is kind hard to maintain this rule of committer must
> sign-off, shouldn't we actually just check if there is one sign-off by
> one of the maintainers that shall be considered acceptable?
I think most trees don't do rebases. The issue does indeed seem to be
that whoever does a rebase becomes the committer, so you need to make
sure that whenever you rebase you add your sign-off to the commits
initially done by other maintainers (in the range of commits that are
being modified).
> Or perhaps there is some documentation on the matter?
I don't think there's any docs.
Since this looks very painful to fix at this point I'll pull as is
from the initial PR from Oct 1st (since it had fewer warnings).
About the content of the PR there is a whole bunch of things here
(fixes, simple device ID additions) which really look like they should
have been targeting net, not net-next.
Okay, enough complaining ;)
Pulled v1, thanks!
Powered by blists - more mailing lists