[Buildroot] merge windows, package submission standards, procedure ... ?

[Buildroot] merge windows, package submission standards, procedure ... ?

[David Purdy]

Hi all,

As I'd not submitted a package/patch to Buildroot before a few days
ago**, I'm asking if there is:

1.   a specific merge window/timeline that patches need to be in by in
order to make it into a pending release?

2.   anything more specific coding requirements than what is listed
here? : http://buildroot.uclibc.org/buildroot.html#add_packages
[ like checkpatch.pl conformity,  trial build for minimum number of
targets/archs ]

3.  any one single person that I need to get contact (like a "new
packages custodian)?
[at U-Boot for instance they have "custodians" who manage certain
aspects of the git tree]

4.   a need to open a Bug Report for a new package?

thanks, regards,

Dave


**Reference: http://lists.busybox.net/pipermail/buildroot/2012-May/054268.html

[Buildroot] merge windows, package submission standards, procedure ... ?

[Peter Korsgaard]

>>>>> "David" == David Purdy <david.c.purdy@gmail.com> writes:

Hi,

 David> Hi all,
 David> As I'd not submitted a package/patch to Buildroot before a few days
 David> ago**, I'm asking if there is:

 David> 1.   a specific merge window/timeline that patches need to be in by in
 David> order to make it into a pending release?

Yes. We do releases every 3 months (I'll most likely release 2012.05
tonight). After a release has been done, the tree is open for new
features for the next 2 months, after which I put of release (n+1)-rc1,
and no longer add any new features to the main (release) branch. At the
same time I also create a next branch and start adding new feature
patches for the following release. Once the release is out I'll merge
next to the the main branch and the cycle restarts.

 David> 2.   anything more specific coding requirements than what is listed
 David> here? : http://buildroot.uclibc.org/buildroot.html#add_packages
 David> [ like checkpatch.pl conformity,  trial build for minimum number of
 David> targets/archs ]

Nothing really specific. The kernel/u-boot checkpatch is for C code, not
the typical makefile / build system fixes we have in buildroot.

The new asciidoc based manual (make manual-html or
http://buildroot.net/downloads/manual/manual.html has some more details
than the old buildroot.html).

 David> 3.  any one single person that I need to get contact (like a "new
 David> packages custodian)?
 David> [at U-Boot for instance they have "custodians" who manage certain
 David> aspects of the git tree]

Not really. Just post on the mailing list. I'm the maintainer so I will
be one committing the changes to the official tree, but several people
review patches besides me.

 David> 4.   a need to open a Bug Report for a new package?

No, please just post patches on the list.

-- 
Bye, Peter Korsgaard

[Buildroot] merge windows, package submission standards, procedure ... ?

[Thomas Petazzoni]

Le Wed, 30 May 2012 23:06:07 +0200,
Peter Korsgaard <jacmet@sunsite.dk> a ?crit :

>  David> 1.   a specific merge window/timeline that patches need to be
>  David> in by in order to make it into a pending release?
> 
> Yes. We do releases every 3 months (I'll most likely release 2012.05
> tonight). After a release has been done, the tree is open for new
> features for the next 2 months, after which I put of release
> (n+1)-rc1, and no longer add any new features to the main (release)
> branch. At the same time I also create a next branch and start adding
> new feature patches for the following release. Once the release is
> out I'll merge next to the the main branch and the cycle restarts.

Which means that practically speaking, you can send your patches at any
time, without having to worry about whether a merge window is opened or
not.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] merge windows, package submission standards, procedure ... ?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> Which means that practically speaking, you can send your
 Thomas> patches at any time, without having to worry about whether a
 Thomas> merge window is opened or not.

Indeed. Sorry if that wasn't clear.

-- 
Bye, Peter Korsgaard