Re: [Buildroot] [PATCH v2] docs/website: link LTS tooling documentation and staging branch

[Quentin Schulz via buildroot <buildroot@buildroot.org>]

Hi Thomas,

On 8/11/26 2:26 PM, Thomas Perale wrote:
> Users asked where the notes are available and if the information are
> publicly available.
> 
> Those changes clearly explain the location and convention of the staging
> branches and also link to more documentation on how to read the
> annotations.
> 
> Signed-off-by: Thomas Perale <thomas.perale@mind.be>
> ---
> v1 -> v2: took into account review from https://lore.kernel.org/r/<f6b4e9a2-8ee5-4799-960f-36dbf5710da6@cherry.de>

Please don't forget to remove the <> otherwise it's not a valid link.

> ---
>   docs/website/lts.html | 29 +++++++++++++++++++----------
>   1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/docs/website/lts.html b/docs/website/lts.html
> index 3bfd2a4374..7513acc885 100644
> --- a/docs/website/lts.html
> +++ b/docs/website/lts.html
> @@ -166,10 +166,6 @@
>       <br/>
>       <br/>
>   
> -    <p>
> -    More details about the LTS workflow at <a href="https://gitlab.com/buildroot.org/buildroot-lts-tools">buildroot.org/buildroot-lts-tools</a>.
> -    </p>
> -
>       <div id="organization" class="br-lts-section-header">
>           <div class="br-lts-bg-grid"></div>
>           <div class="br-lts-title-box">How we work</div>
> @@ -181,12 +177,25 @@
>       analyze based on the previous week's commits to the master branch. The
>       commits are then annotated to define a list of candidates for the LTS
>       branches.
> -    <br><br>
> -    On Thursday, the candidates are cherry-picked to a staging branch to be
> -    reviewed by the other maintainers. On Thursday evening the branch is
> -    synced with upstream and contributors are notified. Feedback from
> -    users, sponsors and autobuilders are then collected and vulnerability
> -    analyses updated.
> +    </p>
> +
> +    <p>
> +    On Thursday, the candidates are cherry-picked to a staging branch hosted on
> +    <a href="https://gitlab.com/essensium-mind/buildroot/">gitlab.com/essensium-mind/buildroot</a>.
> +    Every maintained branch has a staging branch, with the <code>.x</code>
> +    suffix replaced by <code>.pre</code>. The staging branch allows other
> +    maintainers to review the changes before they are pushed upstream.
> +    </p>
> +
> +    <p>
> +    On Thursday evening, the branch is synced with upstream and contributors

Which timezone :)

We don't need to be precise, so I think something like "Europe time" 
would be precise enough for that purpose.

I appreciate the "synced" term comes from 
https://gitlab.com/buildroot.org/buildroot-lts-tools/-/blob/main/tools/README.md#syncing-pre-and-x-branches 
and is clear to you, but it isn't for me, I read this as the equivalent 
of rebasing 2025.02.pre on top of 2025.02.x in case there were other 
patches pushed since 2025.02.pre branched off 2025.02.x (typical 
workflow if you have multiple maintainers with merge requests to a 
single branch). I also see it being used in the graph in "How we work". 
The only important part to the user I believe is that the .pre branch is 
pushed to the .x upstream branch (and because it's pushed, a mail per 
new commit is sent on the mailing list). Unlike the kernel and Yocto 
stable branch workflows, I seem to have understood that patches in 
Buildroot are directly merged to the stable branch(es), without prior 
public notice on the mailing list (except if they were initially posted 
on the mailing list, by other contributors). Is that correct? If so, I 
suggest to simply reword "sync[ed] with upstream [branch]" with 
"push[ed] to upstream [branch]". What do you think?

> +    are notified. Feedbacks from users, sponsors and autobuilders are then
> +    collected and vulnerability analyses updated.

Feedback is not countable, no trailing s.

Also, I'm not sure what I'm supposed to understand from this sentence. 
What do you do with feedback from users, sponsors and autobuilders? Are 
they visible somewhere? Is this what's reported in e.g. 
https://lore.kernel.org/buildroot/6a545c29.87c5160c.35d6c8.0d2e@mx.google.com/?

For the updated vulnerability analyses, I'm assuming it's the one 
available at security.buildroot.org as listed in the 2. Vulnerability 
tracking & reporting section? The link is for 2025.02.x which is a bit 
weird since 2027.02.x will also be an LTS. Maybe simply point at 
https://security.buildroot.org/ and let the user figure out where to go 
from there?

With the timezone + feedback typo fixed:

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

as the rest can always be improved later on.

Cheers,
Quentin
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot