Re: [docs] [PATCH v2] add basic b4 config file

["Antonin Godard" <antonin.godard@bootlin.com>]

Hi Quentin,

On Fri Feb 7, 2025 at 10:26 AM CET, Quentin Schulz wrote:
> Hi Antonin,
>
> On 2/7/25 10:09 AM, Antonin Godard wrote:
>> Hi Quentin,
>> 
>> On Wed Feb 5, 2025 at 3:02 PM CET, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>>
>>> b4[1] is a very nice tool for mail-based contribution. A config[2] file
>>> exists to set up a few defaults. We can use it to set the To recipients
>>> to always add, in our case the mailing list.
>>>
>>> Because we do not have anything to check for now, disable needs-checking
>>> so patches can be sent without running b4 prep --check.
>>>
>>> Because we do not have any auto-to-cc support (and the implicit one
>>> using scripts/get_maintainer.pl cannot work for us), also disable
>>> needs-auto-to-cc so patches can be sent without running b4 prep
>>> --auto-to-cc.
>>>
>>> [1] https://pypi.org/project/b4/
>>> [2] https://b4.docs.kernel.org/en/latest/config.html
>>>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>>> ---
>>> I'm wondering if we couldn't add some per-patch check as well, checking
>>> that the documentation builds for each for example. Could be added in a
>>> later patch though. Any idea?
>> 
>> I think this is a good idea although I think it would make more sense to build
>> the tip commit only, as doc builds are a bit long? Don't know if this is
>
> Ideally individual patches shouldn't break builds so that bisectability 
> is guaranteed.
>
> At the same time, prep-perpatch-check-cmd currently runs sequentially 
> and Sphinx caches stuff between builds... so probably the first run 
> would be the longest and subsequent ones would benefit from the cache 
> (if we reuse the build output from previous patches).
>
>> possible with b4, though.
>> 
>
> Not yet, see 
> https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/src/b4/ez.py#n1683
>
> Konstantin is typically the only one really working on that, so I'm sure 
> he would appreciate some patches :)
>
> At the same time, I've done some shady stuff with b4 for poky where I 
> check (rather **guess**) if the current patch is the last patch in a 
> series. c.f. 
> https://git.openembedded.org/openembedded-core/tree/scripts/b4-wrapper-poky.py#n44
>
>> In any case we might also use your container scripts for this (which I will get
>> to soon hopefully!).
>> 
>
> That itself may be adding a lot of time to the test since we need to 
> compile the container first. Additionally, remember that absolutely NO 
> message should be output to stdout or stderr by the script otherwise the 
> check is understood as a fail. I'm wondering if we couldn't add support 
> for a PIPE between b4 and the scripts so that we can ask it to print 
> stuff (e.g. "please be patient, this may take a while" and maybe even 
> print some progress). For example, I briefly added some WIP support for 
> patchtest as prep-perpatch-cmd in OE-Core, but it takes a long time 
> before returning something, not very user-friendly :/

Ok, all of that sounds like we could already have a first version of this
scripts that just builds the doc locally (no container), commit-per-commit.

Also, is there an option to opt out of this easily? I wouldn't want to
discourage people to contribute because they are unable to setup the docs build,
if you see what I mean (even though I really encourage them to do so, this saves
me time).

Random idea, but the script could read an env variable that switches to a
container build rather than a local build. So the default behavior is build to
build locally but we could always opt out of it. In any case, I would appreciate
a first version of the script that just does the build locally.

Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com