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

Hi Thomas,

On 8/11/26 3:41 PM, Thomas Perale wrote:
> Hello,
> 
> In reply of:
>> 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 <[email protected]>
>>> ---
>>> v1 -> v2: took into account review from https://lore.kernel.org/r/<[email protected]>
>>
>> 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.
> 
> To be honest the main takeaway should be: "It will be synced by the end of the
> week". The Thursday evening mention came from when Arnout was syncing and no
> longer really apply today.
> 
> I will change to a more vague timing instead.
> 

Works for me, thanks for the clarification.

>> 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?
> 
> Correct.
> 
>> If so, I suggest to simply reword "sync[ed] with upstream [branch]" with "push[ed] to upstream [branch]". What do you think?
> 
> Yes, let's change it to 'push'. Match the git terminology better.
> 

Great!

>>
>>> +    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/[email protected]/?
> 
> Feedback from users are email reaction if a cherry pick landed on a branch it
> should not by mistake or a commit was not cherry picked and the user ask the
> reason.

Ok, not sure it's worth being mentioned as that's typical workflow? If a 
commit that shouldn't have been merged to master gets merged, I'm also 
assuming people will complain and/or send a revert? Since it's pushed to 
the stable branch already, there isn't much they can do to "cancel" this 
that differs from what's happening in master.

Cheers,
Quentin
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot