Den 22.11.2022 20.22, skrev Noralf Trønnes: > > > Den 22.11.2022 19.50, skrev Konstantin Ryabitsev: >> On Tue, Nov 22, 2022 at 06:42:19PM +0100, Noralf Trønnes wrote: >>> The first thing that strikes me is that everyone mentioned in one of the >>> patches get the entire patchset, even stable@xxxxxxxxxxxxxxx (cc'ed in a >>> fixes patch). The first patch touches a core file and as a result a few >>> drivers, so I've cc'ed the driver maintainers in that patch, but now >>> they get the entire patchset where 5 of 6 patches is about a driver that >>> I maintain. So from their point of view, they see a patchset about a >>> driver they don't care about and a patch touching a core file, but from >>> the subject it's not apparent that it touches their driver. I'm afraid >>> that this might result in none of them looking at that patch. In this >>> particular case it's not that important, but in another case it might be. >> >> I did some (unscientific) polling among kernel maintainers and, by a vast >> margin, they always prefer to receive the entire series instead of >> cherry-picked patches -- having the entire series helps provide important >> context for the change they are looking at. >> >> So, this is deliberate and, for now at least, not configurable. Unless you're >> sending 100+ patch series, I doubt anyone will have any problem with receiving >> the whole series instead of individual patches. >> >>> As for the setting up the web endpoint, should I just follow the b4 docs >>> on that? >>> >>> I use b4 version 0.10.1, is that recent enough? >> >> Yes. There will be a 0.10.2 in the near future, but the incoming fixes >> shouldn't make much difference for the b4 send code. >> > > This is what I got: > > $ b4 send --web-auth-verify <challenge string from email> > Signing challenge > Submitting verification to https://lkml.kernel.org/_b4_submit > Traceback (most recent call last): > File "/home/pi/.local/bin/b4", line 8, in <module> > sys.exit(cmd()) > File "/home/pi/.local/lib/python3.10/site-packages/b4/command.py", > line 341, in cmd > cmdargs.func(cmdargs) > File "/home/pi/.local/lib/python3.10/site-packages/b4/command.py", > line 86, in cmd_send > b4.ez.cmd_send(cmdargs) > File "/home/pi/.local/lib/python3.10/site-packages/b4/ez.py", line > 1102, in cmd_send > auth_verify(cmdargs) > File "/home/pi/.local/lib/python3.10/site-packages/b4/ez.py", line > 188, in auth_verify > res = ses.post(endpoint, json=req) > File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, > in post > return self.request('POST', url, data=data, json=json, **kwargs) > File "/usr/lib/python3/dist-packages/requests/sessions.py", line 528, > in request > prep = self.prepare_request(req) > File "/usr/lib/python3/dist-packages/requests/sessions.py", line 456, > in prepare_request > p.prepare( > File "/usr/lib/python3/dist-packages/requests/models.py", line 319, in > prepare > self.prepare_body(data, files, json) > File "/usr/lib/python3/dist-packages/requests/models.py", line 469, in > prepare_body > body = complexjson.dumps(json) > File "/usr/lib/python3.10/json/__init__.py", line 231, in dumps > return _default_encoder.encode(obj) > File "/usr/lib/python3.10/json/encoder.py", line 199, in encode > chunks = self.iterencode(o, _one_shot=True) > File "/usr/lib/python3.10/json/encoder.py", line 257, in iterencode > return _iterencode(o, 0) > File "/usr/lib/python3.10/json/encoder.py", line 179, in default > raise TypeError(f'Object of type {o.__class__.__name__} ' > TypeError: Object of type bytes is not JSON serializable > Konstantin found a workaround, so I was able to push the patches. Here's the result if anyone is interested in seeing the result of using b4 and the web endpoint: https://lore.kernel.org/dri-devel/20221122-gud-shadow-plane-v1-0-9de3afa3383e@xxxxxxxxxxx/ Patchwork gave me a new submitter ID: https://patchwork.freedesktop.org/series/111222/ Noralf.
