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

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.

> 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/[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.
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 <[email protected]>
> 
> as the rest can always be improved later on.
> 
> Cheers,
> Quentin
> _______________________________________________
> buildroot mailing list
> [email protected]
> https://lists.buildroot.org/mailman/listinfo/buildroot

PERALE Thomas
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot