[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas Petazzoni]

Hello,

This is a reminder about the upcoming Buildroot Developer Day, which
wlil take place on Friday 3rd February in Brussels, just before the
FOSDEM conference (http://fosdem.org).

As of today, I have received confirmations from the following
participants:

 * Peter Korsgaard
 * Arnout Vandecapelle
 * Thomas De Schampheleire
 * Luca Ceresoli
 * Yann E. Morin
 * myself

The meeting will take place from 9:30 to 18:00 in a location in
Brussels center that will be communicated to the participants. After
the Buildroot Developer Day, the participants are invited to continue
the discussions at the Beer Event organized by the FOSDEM team.

Are there other people interested in participating to this Buildroot
Developer Day?

So far, no agenda has been defined for this meeting. It would be great
to discuss a list of topics to be discussed at this developer day.

Best regards,

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

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas Petazzoni]

Le Tue, 24 Jan 2012 00:08:12 +0100,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> a ?crit :

> As of today, I have received confirmations from the following
> participants:
> 
>  * Peter Korsgaard
>  * Arnout Vandecapelle
>  * Thomas De Schampheleire
>  * Luca Ceresoli
>  * Yann E. Morin
>  * myself

And I forgot:

   * Maxime Ripard

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

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas De Schampheleire]

On Tue, Jan 24, 2012 at 12:08 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> This is a reminder about the upcoming Buildroot Developer Day, which
> wlil take place on Friday 3rd February in Brussels, just before the
> FOSDEM conference (http://fosdem.org).
>
> As of today, I have received confirmations from the following
> participants:
>
> ?* Peter Korsgaard
> ?* Arnout Vandecapelle
> ?* Thomas De Schampheleire
> ?* Luca Ceresoli
> ?* Yann E. Morin
> ?* myself
>
> The meeting will take place from 9:30 to 18:00 in a location in
> Brussels center that will be communicated to the participants. After
> the Buildroot Developer Day, the participants are invited to continue
> the discussions at the Beer Event organized by the FOSDEM team.
>
> Are there other people interested in participating to this Buildroot
> Developer Day?
>
> So far, no agenda has been defined for this meeting. It would be great
> to discuss a list of topics to be discussed at this developer day.
>

Some topics we could discuss:

- status of some things that were discussed on the previous BDD
-- send-patches
-- testing infrastructure
-- crosstool-ng integration
-- documentation migration
-- out-of-tree builds
-- website update
-- maintenance process / patchwork
-- relocatable toolchain

- things that may need further discussion:
-- license stuff (report generation, ...)
-- finalization of Acked-by / Signed-off-by / Reviewed-by discussion.
We talked about this before, but as far as I know there was no final
decision as to: we'll do it this way.

- future directions for buildroot
-- deprecate customize package
-- ...

I'll let you know if I think of other things.

Best regards,
Thomas

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas Petazzoni]

Hello,

Le Wed, 25 Jan 2012 12:03:12 +0100,
Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :

> Some topics we could discuss:
> 
> - status of some things that were discussed on the previous BDD
> -- send-patches
> -- testing infrastructure
> -- crosstool-ng integration
> -- documentation migration
> -- out-of-tree builds
> -- website update
> -- maintenance process / patchwork
> -- relocatable toolchain
> 
> - things that may need further discussion:
> -- license stuff (report generation, ...)
> -- finalization of Acked-by / Signed-off-by / Reviewed-by discussion.
> We talked about this before, but as far as I know there was no final
> decision as to: we'll do it this way.
> 
> - future directions for buildroot
> -- deprecate customize package
> -- ...
> 
> I'll let you know if I think of other things.

Sounds like a good start. However, I fear that on most topics, no much
progress has been made since the Prague BDD. But this upcoming BDD will
gather more developers, so probably we'll be able to spread the
development effort a bit more, and it's good to make a status on items
that were discussed in previous meetings.

Best regards,

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

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Michael S. Zick]

On Wed January 25 2012, Thomas Petazzoni wrote:
> Hello,
> 
> Le Wed, 25 Jan 2012 12:03:12 +0100,
> Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :
> 
> > Some topics we could discuss:
> > 
> > - status of some things that were discussed on the previous BDD
> > -- send-patches
> > -- testing infrastructure
> > -- crosstool-ng integration
> > -- documentation migration
> > -- out-of-tree builds
> > -- website update
> > -- maintenance process / patchwork
> > -- relocatable toolchain
> > 
> > - things that may need further discussion:
> > -- license stuff (report generation, ...)
> > -- finalization of Acked-by / Signed-off-by / Reviewed-by discussion.
> > We talked about this before, but as far as I know there was no final
> > decision as to: we'll do it this way.
> > 

A suggestion which passed by on the OpenEmbedded M.L. recently that might
fit into that discussion:

On the 'Tested-by:' attribute (if used) then adding a classification of
what that testing covered or did not cover (whichever is most informative).
I.E:

Tested-by: J. Q. Public
Coverage: HP, PA-RISC only
or
Coverage-needed: World

Examples above are invented only to display the coverage attribute names.

Mike

> > - future directions for buildroot
> > -- deprecate customize package
> > -- ...
> > 
> > I'll let you know if I think of other things.
> 
> Sounds like a good start. However, I fear that on most topics, no much
> progress has been made since the Prague BDD. But this upcoming BDD will
> gather more developers, so probably we'll be able to spread the
> development effort a bit more, and it's good to make a status on items
> that were discussed in previous meetings.
> 
> Best regards,
> 
> Thomas

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Michael S. Zick]

On Wed January 25 2012, Michael S. Zick wrote:
> On Wed January 25 2012, Thomas Petazzoni wrote:
> > Hello,
> > 
> > Le Wed, 25 Jan 2012 12:03:12 +0100,
> > Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :
> > 
> > > Some topics we could discuss:
> > > 
> > > - status of some things that were discussed on the previous BDD
> > > -- send-patches
> > > -- testing infrastructure
> > > -- crosstool-ng integration
> > > -- documentation migration
> > > -- out-of-tree builds
> > > -- website update
> > > -- maintenance process / patchwork
> > > -- relocatable toolchain
> > > 
> > > - things that may need further discussion:
> > > -- license stuff (report generation, ...)
> > > -- finalization of Acked-by / Signed-off-by / Reviewed-by discussion.
> > > We talked about this before, but as far as I know there was no final
> > > decision as to: we'll do it this way.
> > > 
> 
> A suggestion which passed by on the OpenEmbedded M.L. recently that might
>

Oops, wrong credit, should have been: OpenWRT mailing list.

Mike
> fit into that discussion:
> 
> On the 'Tested-by:' attribute (if used) then adding a classification of
> what that testing covered or did not cover (whichever is most informative).
> I.E:
> 
> Tested-by: J. Q. Public
> Coverage: HP, PA-RISC only
> or
> Coverage-needed: World
> 
> Examples above are invented only to display the coverage attribute names.
> 
> Mike
> 
> > > - future directions for buildroot
> > > -- deprecate customize package
> > > -- ...
> > > 
> > > I'll let you know if I think of other things.
> > 
> > Sounds like a good start. However, I fear that on most topics, no much
> > progress has been made since the Prague BDD. But this upcoming BDD will
> > gather more developers, so probably we'll be able to spread the
> > development effort a bit more, and it's good to make a status on items
> > that were discussed in previous meetings.
> > 
> > Best regards,
> > 
> > Thomas
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Arnout Vandecappelle]

On Wednesday 25 January 2012 12:03:12 Thomas De Schampheleire wrote:
> On Tue, Jan 24, 2012 at 12:08 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
[snip]
> > So far, no agenda has been defined for this meeting. It would be great
> > to discuss a list of topics to be discussed at this developer day.
> >
> 
> Some topics we could discuss:
> 
[snip]
> - future directions for buildroot
> -- deprecate customize package
> -- ...

 I have a list of 21 ideas for things that I'd like to change in buildroot.
Any interest in me going over that list?  The most important ones are:

 -- support for overlays (cfr. openembedded)
 -- support for image-in-image (e.g. cpio+kernel on an ext3+grub on an MBR partition)
 -- shared infrastructure for xxx-yyyconfig
 -- shared infrastructure for non-autotools builds

 Also we should make a decision on the host-tools menu that was posted on 
the list before.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas Petazzoni]

Hello,

Le Fri, 27 Jan 2012 11:33:20 +0100,
Arnout Vandecappelle <arnout@mind.be> a ?crit :

>  I have a list of 21 ideas for things that I'd like to change in
> buildroot. Any interest in me going over that list?  The most
> important ones are:
> 
>  -- support for overlays (cfr. openembedded)

Ok. I am not sure how it is possible without making Buildroot way more
complicated, but we can have a look at this.

>  -- support for image-in-image (e.g. cpio+kernel on an ext3+grub on
> an MBR partition)

Ok.

> -- shared infrastructure for xxx-yyyconfig

Not sure what you mean here?

>  -- shared infrastructure for non-autotools builds

We already have GENTARGETS, what else do you want? Of course, we can
create infrastructure for Python modules or other types of build
systems, but I'm not sure this is what you're referring to.

>  Also we should make a decision on the host-tools menu that was
> posted on the list before.

Peter has said he was OK with this during the Prague meeting, so I
think the decision has been taken. It only needs to be applied :-)

Peter: could you try to handle the patches in a more FIFO fashion,
rather than the LIFO fashion you're using these days? There are many
patches that have been waiting for a very long time, while the most
recent patches are being taken into account very quickly. Some
examples: the host tools menu Arnout is referring to, or Maxime
Ripard's patches on the per-package device/permission stuff.

Best regards,

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

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Peter Korsgaard]

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

Hi,

 Thomas> Peter: could you try to handle the patches in a more FIFO fashion,
 Thomas> rather than the LIFO fashion you're using these days? There are many
 Thomas> patches that have been waiting for a very long time, while the most
 Thomas> recent patches are being taken into account very quickly. Some
 Thomas> examples: the host tools menu Arnout is referring to, or Maxime
 Thomas> Ripard's patches on the per-package device/permission stuff.

Completely FIFO is not an option with the current backlog as updates are
sometimes sent and the latest version should be used, but I agree - The
situation is not optimal.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas Petazzoni]

Le Fri, 27 Jan 2012 16:24:27 +0100,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> Completely FIFO is not an option with the current backlog as updates
> are sometimes sent and the latest version should be used, but I agree
> - The situation is not optimal.

Yeah, of course full FIFO will not work. I just wanted to point out
some of the patch sets that have been sitting around for a while. But
agreed, the most recent patches are the one that have the highest
chance of applying properly, so it's definitely easier to handle them.

Regards,

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

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Yegor Yefremov]

Am 27.01.2012 16:27, schrieb Thomas Petazzoni:
> Le Fri, 27 Jan 2012 16:24:27 +0100,
> Peter Korsgaard <jacmet@uclibc.org> a ?crit :
> 
>> Completely FIFO is not an option with the current backlog as updates
>> are sometimes sent and the latest version should be used, but I agree
>> - The situation is not optimal.
> 
> Yeah, of course full FIFO will not work. I just wanted to point out
> some of the patch sets that have been sitting around for a while. But
> agreed, the most recent patches are the one that have the highest
> chance of applying properly, so it's definitely easier to handle them.

That's where such tools as gerrit and build server come in play, cause they perform automatic integration build and let you know if patch is broken or breaks something.

Best regards,
Yegor

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas Petazzoni]

Le Fri, 27 Jan 2012 16:32:02 +0100,
Yegor Yefremov <yegor_sub1@visionsystems.de> a ?crit :

> That's where such tools as gerrit and build server come in play,
> cause they perform automatic integration build and let you know if
> patch is broken or breaks something.

Unfortunately, it doesn't work this way with Buildroot. There is no
such thing as "the build works" or "the build doesn't work" as in a
regular software. Depending on what the patch modifies, a different set
of configuration options needs to be set in order to test that the patch
actually works. With regular software, you can easily test build a few
configuration options (debug vs. release mode, support of this or
support of that), but Buildroot has millions of different possibles
combinations, which your build server cannot test within a reasonable
time. So only an human being can decide "Hmm, for this patch, I will
try out this config and this config and this config, because those
configs are the one that will make actual use of the patch".

Best regards,

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

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Yegor Yefremov]

Am 27.01.2012 16:36, schrieb Thomas Petazzoni:
> Le Fri, 27 Jan 2012 16:32:02 +0100,
> Yegor Yefremov <yegor_sub1@visionsystems.de> a ?crit :
>
>> That's where such tools as gerrit and build server come in play,
>> cause they perform automatic integration build and let you know if
>> patch is broken or breaks something.
> Unfortunately, it doesn't work this way with Buildroot. There is no
> such thing as "the build works" or "the build doesn't work" as in a
> regular software. Depending on what the patch modifies, a different set
> of configuration options needs to be set in order to test that the patch
> actually works. With regular software, you can easily test build a few
> configuration options (debug vs. release mode, support of this or
> support of that), but Buildroot has millions of different possibles
> combinations, which your build server cannot test within a reasonable
> time. So only an human being can decide "Hmm, for this patch, I will
> try out this config and this config and this config, because those
> configs are the one that will make actual use of the patch".

I see your point. So the only useful features were:

1. keeping all patches at one place
2. automatic checks for applying patches (not building)

Yegor

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas Petazzoni]

Le Fri, 27 Jan 2012 16:50:59 +0100,
Yegor Yefremov <yegor_sub1@visionsystems.de> a ?crit :

> 1. keeping all patches at one place
> 2. automatic checks for applying patches (not building)

Yes. Which is why during the Prague meeting, we discussed using
patchwork and the decision was to try to set it up somewhere.

Best regards,

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

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Peter Korsgaard]

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

 Thomas> Le Fri, 27 Jan 2012 16:50:59 +0100,
 Thomas> Yegor Yefremov <yegor_sub1@visionsystems.de> a ?crit :

 >> 1. keeping all patches at one place
 >> 2. automatic checks for applying patches (not building)

 Thomas> Yes. Which is why during the Prague meeting, we discussed using
 Thomas> patchwork and the decision was to try to set it up somewhere.

.. But I didn't manage to find time to do so yet.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas De Schampheleire]

On Fri, Jan 27, 2012 at 11:33 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On Wednesday 25 January 2012 12:03:12 Thomas De Schampheleire wrote:
>> On Tue, Jan 24, 2012 at 12:08 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
> [snip]
>> > So far, no agenda has been defined for this meeting. It would be great
>> > to discuss a list of topics to be discussed at this developer day.
>> >
>>
>> Some topics we could discuss:
>>
> [snip]
>> - future directions for buildroot
>> -- deprecate customize package
>> -- ...
>
> ?I have a list of 21 ideas for things that I'd like to change in buildroot.
> Any interest in me going over that list? ?The most important ones are:
>
> ?-- support for overlays (cfr. openembedded)
> ?-- support for image-in-image (e.g. cpio+kernel on an ext3+grub on an MBR partition)
> ?-- shared infrastructure for xxx-yyyconfig
> ?-- shared infrastructure for non-autotools builds
>
> ?Also we should make a decision on the host-tools menu that was posted on
> the list before.

Another thing that came to mind recently: if you want to use the same
buildroot sources for two projects (instead of forking them), then you
may end up with conflicts on package versions. For example, the first
project may use a certain kernel version, which causes certain
packages like iproute2 to need a certain version, while the other
project uses a different kernel version and thus a different version
of some packages.
Or maybe independent from the kernel, for some reason a project may
need different package versions.
For most packages, the version to be used is hardcoded in the .mk
file. For others, like gdb, there is a choice of versions via the
.config file. I understand we cannot supply such gdb-like
configuration for all packages as that would be way overkill. However,
another mechanism could be used, e.g. like the source directory
override feature (but then: version override).

And another one: In november I started a discussion on package
patching: http://lists.busybox.net/pipermail/buildroot/2011-November/047505.html
I think we were almost to a conclusion, but it seems I forgot to keep
the thread active and it dried out. So maybe it's worth taking this up
again to reach a conclusion.

Best regards,
Thomas

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> writes:

Hi,

 Thomas> Another thing that came to mind recently: if you want to use the same
 Thomas> buildroot sources for two projects (instead of forking them), then you
 Thomas> may end up with conflicts on package versions. For example, the first
 Thomas> project may use a certain kernel version, which causes certain
 Thomas> packages like iproute2 to need a certain version, while the other
 Thomas> project uses a different kernel version and thus a different version
 Thomas> of some packages.

I've maintained buildroot support for a number of projects at $WORK for
5+ years, and the way I've always handled this is with
branches/tags. Buildroot head moves forward and follows upstream, but
projects might decide to freeze (or if needed branch) once they have a
stable setup. I use the same approach with the Linux kernel and u-boot,
without any real problems.


 Thomas> Or maybe independent from the kernel, for some reason a project may
 Thomas> need different package versions.
 Thomas> For most packages, the version to be used is hardcoded in the .mk
 Thomas> file. For others, like gdb, there is a choice of versions via the
 Thomas> .config file. I understand we cannot supply such gdb-like
 Thomas> configuration for all packages as that would be way overkill. However,
 Thomas> another mechanism could be used, e.g. like the source directory
 Thomas> override feature (but then: version override).

I would prefer to not add too much complexity for such a specialized /
advanced feature.


 Thomas> And another one: In november I started a discussion on package
 Thomas> patching: http://lists.busybox.net/pipermail/buildroot/2011-November/047505.html
 Thomas> I think we were almost to a conclusion, but it seems I forgot to keep
 Thomas> the thread active and it dried out. So maybe it's worth taking this up
 Thomas> again to reach a conclusion.

yes, I think this is good to go, it just needs to be implemented. With
us being this close to 2012.02-rc1 I might wait until I start the next
branch though.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas De Schampheleire]

On Mon, Jan 30, 2012 at 10:42 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> writes:
>
> Hi,
>
> ?Thomas> Another thing that came to mind recently: if you want to use the same
> ?Thomas> buildroot sources for two projects (instead of forking them), then you
> ?Thomas> may end up with conflicts on package versions. For example, the first
> ?Thomas> project may use a certain kernel version, which causes certain
> ?Thomas> packages like iproute2 to need a certain version, while the other
> ?Thomas> project uses a different kernel version and thus a different version
> ?Thomas> of some packages.
>
> I've maintained buildroot support for a number of projects at $WORK for
> 5+ years, and the way I've always handled this is with
> branches/tags. Buildroot head moves forward and follows upstream, but
> projects might decide to freeze (or if needed branch) once they have a
> stable setup. I use the same approach with the Linux kernel and u-boot,
> without any real problems.

Essentially this is the same as creating two independent buildroot
repositories, one for each project. This approach does not have a
single mainstream that allows different configurations for each
project, but rather creates two streams, each with their own
configuration. In my case, since we have many similar but different
products, I'd prefer to be able to keep one stream.

>
>
> ?Thomas> Or maybe independent from the kernel, for some reason a project may
> ?Thomas> need different package versions.
> ?Thomas> For most packages, the version to be used is hardcoded in the .mk
> ?Thomas> file. For others, like gdb, there is a choice of versions via the
> ?Thomas> .config file. I understand we cannot supply such gdb-like
> ?Thomas> configuration for all packages as that would be way overkill. However,
> ?Thomas> another mechanism could be used, e.g. like the source directory
> ?Thomas> override feature (but then: version override).
>
> I would prefer to not add too much complexity for such a specialized /
> advanced feature.

In its basic form, I don't think it has to be very complex. Although I
haven't looked into this in detail, it could be enough to allow to
override FOO_VERSION from the configuration or from a certain
project-specific file.

>
>
> ?Thomas> And another one: In november I started a discussion on package
> ?Thomas> patching: http://lists.busybox.net/pipermail/buildroot/2011-November/047505.html
> ?Thomas> I think we were almost to a conclusion, but it seems I forgot to keep
> ?Thomas> the thread active and it dried out. So maybe it's worth taking this up
> ?Thomas> again to reach a conclusion.
>
> yes, I think this is good to go, it just needs to be implemented. With
> us being this close to 2012.02-rc1 I might wait until I start the next
> branch though.

I understand. I haven't had a lot of time lately either to submit patches.

Best regards,
Thomas

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> writes:

Hi,

 >> I've maintained buildroot support for a number of projects at $WORK for
 >> 5+ years, and the way I've always handled this is with
 >> branches/tags. Buildroot head moves forward and follows upstream, but
 >> projects might decide to freeze (or if needed branch) once they have a
 >> stable setup. I use the same approach with the Linux kernel and u-boot,
 >> without any real problems.

 Thomas> Essentially this is the same as creating two independent buildroot
 Thomas> repositories, one for each project. This approach does not have a
 Thomas> single mainstream that allows different configurations for each
 Thomas> project, but rather creates two streams, each with their own
 Thomas> configuration. In my case, since we have many similar but different
 Thomas> products, I'd prefer to be able to keep one stream.

Here as well. That stream is the head branch. Branching only happens
once a project no longer wants to follow the main development. This
doesn't mean that the project gets removed from the head version, just
that it is no longer used to cut releases from.

 >> I would prefer to not add too much complexity for such a specialized /
 >> advanced feature.

 Thomas> In its basic form, I don't think it has to be very complex. Although I
 Thomas> haven't looked into this in detail, it could be enough to allow to
 Thomas> override FOO_VERSION from the configuration or from a certain
 Thomas> project-specific file.

What about other version dependencies? Patches, different dependencies,
configure options, ..?

 >> yes, I think this is good to go, it just needs to be implemented. With
 >> us being this close to 2012.02-rc1 I might wait until I start the next
 >> branch though.

 Thomas> I understand. I haven't had a lot of time lately either to submit patches.

No problem. I'll do it myself if you don't get around to do it.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Thomas Petazzoni]

Le Mon, 30 Jan 2012 10:19:12 +0100,
Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :

> For most packages, the version to be used is hardcoded in the .mk
> file. For others, like gdb, there is a choice of versions via the
> .config file. I understand we cannot supply such gdb-like
> configuration for all packages as that would be way overkill. However,
> another mechanism could be used, e.g. like the source directory
> override feature (but then: version override).

It is relatively easy to do version override, but the problem is that
if you override the version, most likely you'll also need to override
the other variables: the configuration options change between versions,
the build procedure might change, etc. So in the end we will end up
needing to be able to override everything. We will discuss this on
Friday, but I'm not sure it is possible to do this in a nice and
maintainable way.

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

[Buildroot] Buildroot Developer Day, Friday 3rd February, Brussels

[Luca Ceresoli]

Thomas De Schampheleire wrote:

> On Tue, Jan 24, 2012 at 12:08 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>  wrote:
>> Hello,
>>
>> This is a reminder about the upcoming Buildroot Developer Day, which
>> wlil take place on Friday 3rd February in Brussels, just before the
>> FOSDEM conference (http://fosdem.org).
>>
>> As of today, I have received confirmations from the following
>> participants:
>>
>>   * Peter Korsgaard
>>   * Arnout Vandecapelle
>>   * Thomas De Schampheleire
>>   * Luca Ceresoli
>>   * Yann E. Morin
>>   * myself
>>
>> The meeting will take place from 9:30 to 18:00 in a location in
>> Brussels center that will be communicated to the participants. After
>> the Buildroot Developer Day, the participants are invited to continue
>> the discussions at the Beer Event organized by the FOSDEM team.
>>
>> Are there other people interested in participating to this Buildroot
>> Developer Day?
>>
>> So far, no agenda has been defined for this meeting. It would be great
>> to discuss a list of topics to be discussed at this developer day.
>>
> Some topics we could discuss:
>
> - status of some things that were discussed on the previous BDD
> -- send-patches
> -- testing infrastructure
> -- crosstool-ng integration
> -- documentation migration
> -- out-of-tree builds
> -- website update
> -- maintenance process / patchwork
> -- relocatable toolchain
>
> - things that may need further discussion:
> -- license stuff (report generation, ...)
I've just posted an RFC patchset with a draft implementation of this
feature, with the hope this can be a good starting point for the discussion
during the BDD.

Luca