[Buildroot] Merge window

[Buildroot] Merge window

[Joachim Nilsson]

Hi,

I'm new to the Buildroot community and am curious to learn more about
the development process, in particular if there is any merge window to
consider when submitting patches?  I've combed through the (fantastic)
documentation, but not found any mention of this.  Seeing as there are
a few brave souls who seem to do much of the legwork in this project,
I worry about the timing of patches and questions as to not wear down
or disturb at the wrong time.

I recently submitted my first patch to add support for the EspressoBin
which has not yet gotten any response.  So I'm thinking my timing was
bad, considering you seem to be preparing a new release, or maybe I
missed Cc:ing someone.  Should I resend the patch at a better time?

Best regards
 /Joachim

[Buildroot] Merge window

[Patzlaff, Marcel]

Hi Joachim,

it's not required (unless requested by the maintainers) to resend patches. They happily wait for their time to be merged [1].

Kind regards,
Marcel

[1]: https://patchwork.ozlabs.org/project/buildroot/list/

-----Urspr?ngliche Nachricht-----
Von: buildroot <buildroot-bounces@busybox.net> Im Auftrag von Joachim Nilsson
Gesendet: Freitag, 22. Mai 2020 10:15
An: Buildroot <buildroot@buildroot.org>
Betreff: [Buildroot] Merge window

Hi,

I'm new to the Buildroot community and am curious to learn more about the development process, in particular if there is any merge window to consider when submitting patches?  I've combed through the (fantastic) documentation, but not found any mention of this.  Seeing as there are a few brave souls who seem to do much of the legwork in this project, I worry about the timing of patches and questions as to not wear down or disturb at the wrong time.

I recently submitted my first patch to add support for the EspressoBin which has not yet gotten any response.  So I'm thinking my timing was bad, considering you seem to be preparing a new release, or maybe I missed Cc:ing someone.  Should I resend the patch at a better time?

Best regards
 /Joachim

_______________________________________________
buildroot mailing list
buildroot at busybox.net
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.busybox.net%2Fmailman%2Flistinfo%2Fbuildroot&amp;data=02%7C01%7C%7Ced82e827596a476716e508d7fe2b1415%7C92bd06fd7d0b494a8f770e63d2bf3a3e%7C0%7C0%7C637257333294015051&amp;sdata=wQeACUs7UfG4mLF7YwAIGph4kF4KK2GHphzVJojUN7g%3D&amp;reserved=0

[Buildroot] Merge window

[Joachim Nilsson]

On Fri May 22, 2020 at 10:48 AM CEST, Patzlaff, Marcel wrote:
> Hi Joachim,

Hi Marcel,

> it's not required (unless requested by the maintainers) to resend
> patches. They happily wait for their time to be merged [1].
> [1]: https://patchwork.ozlabs.org/project/buildroot/list/

Aha, thank you for taking the time to respond! :)

Best regards
 /Joachim

[Buildroot] Merge window

[Peter Korsgaard]

>>>>> "Joachim" == Joachim Nilsson <troglobit@gmail.com> writes:

 > Hi,
 > I'm new to the Buildroot community and am curious to learn more about
 > the development process, in particular if there is any merge window to
 > consider when submitting patches?  I've combed through the (fantastic)
 > documentation, but not found any mention of this.  Seeing as there are
 > a few brave souls who seem to do much of the legwork in this project,
 > I worry about the timing of patches and questions as to not wear down
 > or disturb at the wrong time.

We indeed don't really have it written down anywhere, but the process
is:

Releases every 3 months (.02, .05, .08, .11), with montly bugfix
releases (2020.02.1, 2020.02.2, ..). Normal releases are supported until
the first bugfix release of the next release (E.G. 2020.05.x is EOL when
2020.08.1 is released), and the first release of each year
(E.G. 2020.02) is a long term release which is supported until the first
bugfix release of the next LTS (E.G. 2021.02.1).

Development happens on the master git branch. Within each 3 month
development cycle we have ~2 months of development, followed by
RC1. After that point no new features are added to master, only
bugfixes. To handle new features / version bumps during the
stabilization phase we create a next branch where these are added. Once
the release has been made, next is merged into master and the new
development continues on master.

It would be good to add something like this to the manual. Would you be
interested in working on that?

 > I recently submitted my first patch to add support for the EspressoBin
 > which has not yet gotten any response.  So I'm thinking my timing was
 > bad, considering you seem to be preparing a new release, or maybe I
 > missed Cc:ing someone.  Should I resend the patch at a better time?

As explained above, new features can be added at any time (master or
next depending on where we are in the cycle). Patches are tracked in
patchwork:

https://patchwork.ozlabs.org/project/buildroot/list/

The reason why your patch has not gotten any feedback is simply that we
get a lot of patches. The backlog is currently at 470 patches.

-- 
Bye, Peter Korsgaard

[Buildroot] Merge window

[Joachim Nilsson]

On Fri May 22, 2020 at 1:29 PM CEST, Peter Korsgaard wrote:
> [snip]
> It would be good to add something like this to the manual. Would you be
> interested in working on that?

Sure, how about something like this, or were you thinking about something
more?  I can whip up a real patch for further comments.

--8<-----------------------------------------------------------------
== Release Engineering

The Buildroot project makes quarterly releases with monthly bugfix
releases.  The first release of each year is a long term support
release, LTS.

 - Quarterly releases: 2020.02, 2020.05, 2020.08, and 2020.11
 - Bugfix releases: 2020.02.1, 2020.02.2, ...
 - LTS releases: 2020.02, 2021.02, ...

Releases are supported until the first bugfix release of the next
release, e.g., 2020.05.x is EOL when 2020.08.1 is released.

LTS releases are supported until the first bugfix release of the next
LTS, e.g., 2020.02.x is supported until 2021.02.1 is released.

=== Development

Each release cycle consist of two months of development on the +master+
branch and one month stabilization before the release is made.  During
this phase no new features are added to +master+, only bugfixes.

The stabilization phase starts with tagging +-rc1+, every week until the
release, another release candidate is tagged.

To handle new features and version bumps during the stabilization phase,
a +next+ branch may be created for these features.  Once the current
release has been made, the +next+ branch is merged into +master+ and
the development cycle for the next release continues there.
--8<-----------------------------------------------------------------

> The reason why your patch has not gotten any feedback is simply that we
> get a lot of patches. The backlog is currently at 470 patches.

Woah ... OK, thanks! :)

Best regards
 /Joachim

[Buildroot] Merge window

[Peter Korsgaard]

>>>>> "Joachim" == Joachim Nilsson <troglobit@gmail.com> writes:

 > On Fri May 22, 2020 at 1:29 PM CEST, Peter Korsgaard wrote:
 >> [snip]
 >> It would be good to add something like this to the manual. Would you be
 >> interested in working on that?

 > Sure, how about something like this, or were you thinking about something
 > more?  I can whip up a real patch for further comments.

 > --8<-----------------------------------------------------------------
 > == Release Engineering

 > The Buildroot project makes quarterly releases with monthly bugfix
 > releases.  The first release of each year is a long term support
 > release, LTS.

 >  - Quarterly releases: 2020.02, 2020.05, 2020.08, and 2020.11
 >  - Bugfix releases: 2020.02.1, 2020.02.2, ...
 >  - LTS releases: 2020.02, 2021.02, ...

 > Releases are supported until the first bugfix release of the next
 > release, e.g., 2020.05.x is EOL when 2020.08.1 is released.

 > LTS releases are supported until the first bugfix release of the next
 > LTS, e.g., 2020.02.x is supported until 2021.02.1 is released.

 > === Development

 > Each release cycle consist of two months of development on the +master+
 > branch and one month stabilization before the release is made.  During
 > this phase no new features are added to +master+, only bugfixes.

 > The stabilization phase starts with tagging +-rc1+, every week until the
 > release, another release candidate is tagged.

 > To handle new features and version bumps during the stabilization phase,
 > a +next+ branch may be created for these features.  Once the current
 > release has been made, the +next+ branch is merged into +master+ and
 > the development cycle for the next release continues there.

Looks good to me, thanks. Could you send it as a git patch for easy
applying?

-- 
Bye, Peter Korsgaard