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

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

[Thomas Perale via buildroot]

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>
---
 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
+    are notified. Feedbacks from users, sponsors and autobuilders are then
+    collected and vulnerability analyses updated.
+    </p>
+
+    <p>
+    For more information about the development workflow, see the
+    <a href="https://gitlab.com/buildroot.org/buildroot-lts-tools/-/blob/main/tools/README.md">documentation</a>.
     </p>
     <br/>
 
-- 
2.55.0

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

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

[Quentin Schulz via buildroot]

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

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

[Thomas Perale via buildroot]

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 <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.

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.

> 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.

> 
> > +    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/?

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.
Autobuilder feedback are the build-errors from https://autobuild.buildroot.org/
that may start after pushing some changes.

> 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

PERALE Thomas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Quentin Schulz via buildroot]

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 <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.
> 
> 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/6a545c29.87c5160c.35d6c8.0d2e@mx.google.com/?
> 
> 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
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot