[Buildroot] Still no answer for a contribution made in March

[Buildroot] Still no answer for a contribution made in March

[Thomas Petazzoni]

Hi,

On March, 12th, I sent a patch adding Thumb support for the ARM
architecture to this list:
 http://buildroot.uclibc.org/lists/buildroot/2008-March/007427.html

Two days later, no comments:
 http://buildroot.uclibc.org/lists/buildroot/2008-March/007492.html

Five days later, no comments:
 http://buildroot.uclibc.org/lists/buildroot/2008-March/007544.html

Two months later, still no comments:
 http://buildroot.uclibc.org/lists/buildroot/2008-May/008723.html

Do you actually care of contributions ?

I don't assume that my patch is perfect or absolutely useful for
everybody, but I would have at least expected some reaction from
Buildroot maintainers saying: ?no, thank you, we don't care about this
feature? or ?interesting feature, but your approach is flawed because of
this and that?.

FWIW, one user reported interest in such a feature:
 http://buildroot.uclibc.org/lists/buildroot/2008-March/007495.html

This absence of reaction is very frustrating for new potential
contributors. I would like to contribute more to Buildroot, but this
experience doesn't really encourage one in spending more time writing
patches that will be ignored.

Thanks a lot for this great project,

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080611/2c41229b/attachment.pgp 

[Buildroot] Still no answer for a contribution made in March

[Bernhard Fischer]

On Wed, Jun 11, 2008 at 04:11:56PM +0200, Thomas Petazzoni wrote:
>Hi,
>
>On March, 12th, I sent a patch adding Thumb support for the ARM
>architecture to this list:

>I don't assume that my patch is perfect or absolutely useful for
>everybody, but I would have at least expected some reaction from
>Buildroot maintainers saying: ?no, thank you, we don't care about this
>feature? or ?interesting feature, but your approach is flawed because of
>this and that?.

You can do all this already, via the "additional" config options and
CFLAGS, fwiw.

[Buildroot] Still no answer for a contribution made in March

[John Voltz]

Hi Thomas,

I would have expected Ulf to take care of your patch since he usually
handles most of the ARM stuff. I've noticed that one of the important
methods of working with free software is to be able to make the changes
directly yourself. So I would email Erik for subversion access, and drop it
in there myself. If nobody on the list seems to be actively doing things,
just do it yourself. It's not because nobody cares or nodoby is interested,
people like me only work on it in our spare time. Also, I don't know
anything about the ARM so I try to avoid making changes in areas I can't
support in the future.

Just my two cents.

John Voltz


On Wed, Jun 11, 2008 at 10:11 AM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> Hi,
>
> On March, 12th, I sent a patch adding Thumb support for the ARM
> architecture to this list:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007427.html
>
> Two days later, no comments:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007492.html
>
> Five days later, no comments:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007544.html
>
> Two months later, still no comments:
>  http://buildroot.uclibc.org/lists/buildroot/2008-May/008723.html
>
> Do you actually care of contributions ?
>
> I don't assume that my patch is perfect or absolutely useful for
> everybody, but I would have at least expected some reaction from
> Buildroot maintainers saying: ?no, thank you, we don't care about this
> feature? or ?interesting feature, but your approach is flawed because of
> this and that?.
>
> FWIW, one user reported interest in such a feature:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007495.html
>
> This absence of reaction is very frustrating for new potential
> contributors. I would like to contribute more to Buildroot, but this
> experience doesn't really encourage one in spending more time writing
> patches that will be ignored.
>
> Thanks a lot for this great project,
>
> Sincerly,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers and embedded Linux development,
> consulting, training and support.
> http://free-electrons.com
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080611/297674d5/attachment.htm 

[Buildroot] Still no answer for a contribution made in March

[Bernhard Fischer]

On Wed, Jun 11, 2008 at 04:11:56PM +0200, Thomas Petazzoni wrote:
>Hi,
>
>On March, 12th, I sent a patch adding Thumb support for the ARM
>architecture to this list:
> http://buildroot.uclibc.org/lists/buildroot/2008-March/007427.html

I moved this into the build options where it fits better.

Applied, thanks!

[Buildroot] Still no answer for a contribution made in March

[Bernhard Fischer]

On Wed, Jun 11, 2008 at 11:08:49AM -0400, John Voltz wrote:
>Hi Thomas,
>
>I would have expected Ulf to take care of your patch since he usually
>handles most of the ARM stuff. I've noticed that one of the important
>methods of working with free software is to be able to make the changes
>directly yourself. So I would email Erik for subversion access, and drop it
>in there myself.

Yea, and that's the reason why the svn-repo is completely fux0red up.

>                 If nobody on the list seems to be actively doing things,
>just do it yourself. It's not because nobody cares or nodoby is interested,
>people like me only work on it in our spare time. Also, I don't know
>anything about the ARM so I try to avoid making changes in areas I can't
>support in the future.

I have applied it but i suspect that it's not really correct to just build
libc with interwork and building _everything_ else without it. Not much
harm since one can turn it off easily until somebody takes a close look.

Also the location in the configs was not really appropriate.
>
>Just my two cents.

make that four

[Buildroot] Still no answer for a contribution made in March

[Kieran Bingham]

I agree,

I posted a patch regarding a simple fix to the buildroot 
gcc-uclibc-[34].x.mk files

I have been working on getting SH2a toolchain support into buildroot, 
and was "Dipping my toes in" with this first patch.

Without response, I'm not convinced I should take the time and effort to 
bother creating patches to provide support in mainline buildroot.

Is there any ACK/NACK procedure that could be taken on even basic 
patches by maintainers ?


Thomas Petazzoni wrote:
> FWIW, one user reported interest in such a feature:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007495.html
>
> This absence of reaction is very frustrating for new potential
> contributors. I would like to contribute more to Buildroot, 
Completely agree with these sentiments.
> but this
> experience doesn't really encourage one in spending more time writing
> patches that will be ignored.
>
> Thanks a lot for this great project,
>   
And these :)
> Sincerly,
>
> Thomas
>   
>   
--
Best Regards
Kieran Bingham

[Buildroot] Still no answer for a contribution made in March

[Thomas Petazzoni]

Hi John,

Thanks for your answer.

Le Wed, 11 Jun 2008 11:08:49 -0400,
"John Voltz" <john.voltz@gmail.com> a ?crit :

> I would have expected Ulf to take care of your patch since he usually
> handles most of the ARM stuff. I've noticed that one of the important
> methods of working with free software is to be able to make the
> changes directly yourself.

And another more important thing in free software is peer-review and
patch discussion :-)

More seriously, I am not a regular contributor to Buildroot, so I have
no idea what are the current trends and orientations, nor what are the
good approaches to solve a particular problem. So I think that my
patches have to be reviewed before being applied.

> So I would email Erik for subversion access, and drop it in there
> myself.

As explained above, I don't want to do that now. I consider my
Buildroot contributing experience too small to commit patches without
prior discussion and review.

Thanks !

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080611/875ebdbe/attachment-0001.pgp 

[Buildroot] Still no answer for a contribution made in March

[John Voltz]

> Yea, and that's the reason why the svn-repo is completely fux0red up.
>
> There is a very similar discussion going on at Slashdot this morning about
X.org and how it has completely stagnated. Nobody is really fixing the bugs
and it seems to be the consensus (at least on Slashdot) that if people in
the community are not happy with the rate of changes they should get
involved themselves. Still, somebody needs to manage the project to make
sure it doesn't turn to crap. I don't think there is an easy answer to the
problem. The end user is always going to need to know a lot about the
project to make sure it works for them.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080611/618756f5/attachment.htm 

[Buildroot] Still no answer for a contribution made in March

[Bernhard Fischer]

On Wed, Jun 11, 2008 at 12:03:52PM -0400, John Voltz wrote:

>> There is a very similar discussion going on at Slashdot this morning about
>X.org and how it has completely stagnated. Nobody is really fixing the bugs
>and it seems to be the consensus (at least on Slashdot) that if people in
>the community are not happy with the rate of changes they should get
>involved themselves.

I let you guys use the stuff that apparently works for you, sure. It
doesn't work for me, and i was not interrested in fruitless arguments
about taste so i went away after playing patch-monkey for quite some
time.

>                     Still, somebody needs to manage the project to make
>sure it doesn't turn to crap. I don't think there is an easy answer to the

The "we can fix it later" attitude only works to some small degree,
YMMV.

>problem. The end user is always going to need to know a lot about the
>project to make sure it works for them.

[Buildroot] Still no answer for a contribution made in March

[Ulf Samuelsson]

> Hi Thomas,

> I would have expected Ulf to take care of your patch since he usually
> handles most of the ARM stuff.

I am short of time.
There is a lot that needs fixing,

* Use U-Boot-1.3.4 for AT91
* Migration of patches allowing buildroot to configure U-Boot.
* Update external toolchain for AVR32.
* Addition of some new devices. (AT572D940 Diopsis, SAM9RL, the AT32AP7200).

I won't be too active until August - unless it is raining.
There is also European Football Championship and Olympics that will 
interfere...
Go Zlatan go!

Best Regards
Ulf Samuelsson


I've noticed that one of the important
methods of working with free software is to be able to make the changes
directly yourself. So I would email Erik for subversion access, and drop it
in there myself. If nobody on the list seems to be actively doing things,
just do it yourself. It's not because nobody cares or nodoby is interested,
people like me only work on it in our spare time. Also, I don't know
anything about the ARM so I try to avoid making changes in areas I can't
support in the future.

Just my two cents.

John Voltz


On Wed, Jun 11, 2008 at 10:11 AM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> Hi,
>
> On March, 12th, I sent a patch adding Thumb support for the ARM
> architecture to this list:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007427.html
>
> Two days later, no comments:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007492.html
>
> Five days later, no comments:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007544.html
>
> Two months later, still no comments:
>  http://buildroot.uclibc.org/lists/buildroot/2008-May/008723.html
>
> Do you actually care of contributions ?
>
> I don't assume that my patch is perfect or absolutely useful for
> everybody, but I would have at least expected some reaction from
> Buildroot maintainers saying: ?no, thank you, we don't care about this
> feature? or ?interesting feature, but your approach is flawed because of
> this and that?.
>
> FWIW, one user reported interest in such a feature:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007495.html
>
> This absence of reaction is very frustrating for new potential
> contributors. I would like to contribute more to Buildroot, but this
> experience doesn't really encourage one in spending more time writing
> patches that will be ignored.
>
> Thanks a lot for this great project,
>
> Sincerly,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers and embedded Linux development,
> consulting, training and support.
> http://free-electrons.com
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>



--------------------------------------------------------------------------------


> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot 

[Buildroot] Still no answer for a contribution made in March

[Hamish Moffatt]

On Wed, Jun 11, 2008 at 05:41:21PM +0200, Bernhard Fischer wrote:
> On Wed, Jun 11, 2008 at 11:08:49AM -0400, John Voltz wrote:
> >Hi Thomas,
> >
> >I would have expected Ulf to take care of your patch since he usually
> >handles most of the ARM stuff. I've noticed that one of the important
> >methods of working with free software is to be able to make the changes
> >directly yourself. So I would email Erik for subversion access, and drop it
> >in there myself.
> 
> Yea, and that's the reason why the svn-repo is completely fux0red up.

What reason? How does that follow?


Thanks
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Still no answer for a contribution made in March

[Peter Korsgaard]

>>>>> "Kieran" == Kieran Bingham <kieranbingham@gmail.com> writes:

 Kieran> I agree,
 Kieran> I posted a patch regarding a simple fix to the buildroot 
 Kieran> gcc-uclibc-[34].x.mk files

Link? I've been really busy, and must have missed it.

 Kieran> I have been working on getting SH2a toolchain support into
 Kieran> buildroot, and was "Dipping my toes in" with this first
 Kieran> patch.

 Kieran> Without response, I'm not convinced I should take the time
 Kieran> and effort to bother creating patches to provide support in
 Kieran> mainline buildroot.

It's your call ofcause, but please do.

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution made in March

[Thomas Petazzoni]

Le Wed, 11 Jun 2008 17:41:21 +0200,
Bernhard Fischer <rep.dot.nop@gmail.com> a ?crit :

> Yea, and that's the reason why the svn-repo is completely fux0red up.

I don't necessarly think so. Here, the issue is not a bottleneck at the
commit level, but rather a patch review bandwidth problem.

What's the relationship between your Git repo and the official
Subversion tree ? When is your tree pulled into the official Subversion
tree ? Who review the patches and when ?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080612/8d5064ee/attachment.pgp 

[Buildroot] Still no answer for a contribution made in March

[Peter Korsgaard]

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

Hi,

 >> Yea, and that's the reason why the svn-repo is completely fux0red up.

 Thomas> I don't necessarly think so. Here, the issue is not a bottleneck at the
 Thomas> commit level, but rather a patch review bandwidth problem.

Agree - And lack of testing before stuff gets checked in. The deeper
issue is that we don't do releases I guess, so there's a tension
between doing development, and having something stable for actual use.

I have gotten a login to the gcc cluster, and have plans to setup a
buildbot instance to do regression tests on buildroot.

 Thomas> What's the relationship between your Git repo and the
 Thomas> official Subversion tree ? When is your tree pulled into the
 Thomas> official Subversion tree ? Who review the patches and when ?

Bernard's git tree is a fork of the svn repo from some time
ago. There's no official sync, but he sometimes cherrypicks commits
from svn, and I sometimes do the same from his tree.

It's a pity, but has historical reasons.

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution made in March

[Bernhard Fischer]

On Thu, Jun 12, 2008 at 03:21:46PM +1000, Hamish Moffatt wrote:
>On Wed, Jun 11, 2008 at 05:41:21PM +0200, Bernhard Fischer wrote:
>> On Wed, Jun 11, 2008 at 11:08:49AM -0400, John Voltz wrote:
>> >Hi Thomas,
>> >
>> >I would have expected Ulf to take care of your patch since he usually
>> >handles most of the ARM stuff. I've noticed that one of the important
>> >methods of working with free software is to be able to make the changes
>> >directly yourself. So I would email Erik for subversion access, and drop it
>> >in there myself.
>> 
>> Yea, and that's the reason why the svn-repo is completely fux0red up.
>
>What reason? How does that follow?

Many reasons. Ask yourself if you use proper flags, to name just the
most visible one. But even apart from that there are numerous, just for
example, random picks:
http://buildroot.uclibc.org/lists/buildroot/2007-September/005051.html
http://buildroot.uclibc.org/lists/buildroot/2008-January/006696.html
http://buildroot.uclibc.org/lists/buildroot/2008-February/006971.html
http://buildroot.uclibc.org/lists/buildroot/2008-April/007981.html
http://buildroot.uclibc.org/lists/buildroot/2008-April/008480.html
http://buildroot.uclibc.org/lists/buildroot/2008-April/008494.html
etc, etc

[Buildroot] Still no answer for a contribution made in March

[Ulf Samuelsson]

To: <buildroot@uclibc.org>
Sent: Thursday, June 12, 2008 1:13 PM
Subject: Re: [Buildroot] Still no answer for a contribution made in March


> On Thu, Jun 12, 2008 at 03:21:46PM +1000, Hamish Moffatt wrote:
>>On Wed, Jun 11, 2008 at 05:41:21PM +0200, Bernhard Fischer wrote:
>>> On Wed, Jun 11, 2008 at 11:08:49AM -0400, John Voltz wrote:
>>> >Hi Thomas,
>>> >
>>> >I would have expected Ulf to take care of your patch since he usually
>>> >handles most of the ARM stuff. I've noticed that one of the important
>>> >methods of working with free software is to be able to make the changes
>>> >directly yourself. So I would email Erik for subversion access, and drop it
>>> >in there myself.
>>> 
>>> Yea, and that's the reason why the svn-repo is completely fux0red up.
>>
>>What reason? How does that follow?
> 
> Many reasons. Ask yourself if you use proper flags, to name just the
> most visible one. But even apart from that there are numerous, just for
> example, random picks:
> http://buildroot.uclibc.org/lists/buildroot/2007-September/005051.html

Yes, you broke the AT91 ARM build (which depends on ATMEL_MIRROR),
by making the ATMEL_MIRROR definition dependent on using the AVR32 architecture.
That is why the patch was reverted.

You may be right on the others.

> http://buildroot.uclibc.org/lists/buildroot/2008-January/006696.html
> http://buildroot.uclibc.org/lists/buildroot/2008-February/006971.html
> http://buildroot.uclibc.org/lists/buildroot/2008-April/007981.html
> http://buildroot.uclibc.org/lists/buildroot/2008-April/008480.html
> http://buildroot.uclibc.org/lists/buildroot/2008-April/008494.html
> etc, etc
> _______________________________________________


Best Regards
Ulf Samuelsson

[Buildroot] Still no answer for a contribution made in March

[Ulf Samuelsson]

> Hi,
> 
> >> Yea, and that's the reason why the svn-repo is completely fux0red up.
> 
> Thomas> I don't necessarly think so. Here, the issue is not a bottleneck at the
> Thomas> commit level, but rather a patch review bandwidth problem.
> 
> Agree - And lack of testing before stuff gets checked in. The deeper
> issue is that we don't do releases I guess, so there's a tension
> between doing development, and having something stable for actual use.
> 

Maybe we should start?

Other project are using "git" and is sneering at "svn".
Should we change?

> I have gotten a login to the gcc cluster, and have plans to setup a
> buildbot instance to do regression tests on buildroot.
> 
> Thomas> What's the relationship between your Git repo and the
> Thomas> official Subversion tree ? When is your tree pulled into the
> Thomas> official Subversion tree ? Who review the patches and when ?
> 
> Bernard's git tree is a fork of the svn repo from some time
> ago. There's no official sync, but he sometimes cherrypicks commits
> from svn, and I sometimes do the same from his tree.
> 
> It's a pity, but has historical reasons.
> 
> -- 


Best Regards
Ulf Samuelsson

[Buildroot] Still no answer for a contribution made in March

[Thomas Petazzoni]

Hi,

Le Thu, 12 Jun 2008 10:42:30 +0200,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> Agree - And lack of testing before stuff gets checked in. The deeper
> issue is that we don't do releases I guess, so there's a tension
> between doing development, and having something stable for actual use.

True. Doing stable release would probably be useful for Buildroot
users, and would help in testing something more or less completely.
It's probably a topic that has already been discussed on the
mailing-list, I didn't look in the archives.

> I have gotten a login to the gcc cluster, and have plans to setup a
> buildbot instance to do regression tests on buildroot.

Sounds great.

> Bernard's git tree is a fork of the svn repo from some time
> ago. There's no official sync, but he sometimes cherrypicks commits
> from svn, and I sometimes do the same from his tree.
> 
> It's a pity, but has historical reasons.

What tree should a new user use ? The git tree doesn't seem to be
referenced anywhere. Isn't it possible to find a solution to get back
to a single officiel tree ?

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080612/f80a74ba/attachment.pgp 

[Buildroot] Still no answer for a contribution made in March

[David Anders]

Ulf,

> 
> Maybe we should start?
> 

i whole heartedly agree there needs to be buildroot releases. the constant state of dev for
buildroot creates a fractured community with many people keeping their own repo of stable builds.

> Other project are using "git" and is sneering at "svn".
> Should we change?
> 

moving to git is a terrible idea, imho. i know this will probably start a flame war, but svn is
far more usable for those of us that use buildroot for commercial products. even offshoots of
OpenEmbedded such as Poky(http://www.pokylinux.org) use svn. just because linus uses it for kernel
doesn't make it a panacea for every project's source code revision control.


Dave



      

[Buildroot] Still no answer for a contribution made in March

[sjhill at realitydiluted.com]

> Maybe we should start?
> 
> Other project are using "git" and is sneering at "svn".
> Should we change?
> 
I vote to leave things in Subversion. git is a resource pig and to move
SCM systems for one or two developers does not seem like a big enough
deal to me.

-Steve

[Buildroot] Still no answer for a contribution made in March

[John Voltz]

>
>
> > Other project are using "git" and is sneering at "svn".
> > Should we change?
> >
>

To make an informed decision, everyone ought to read this:

http://git.or.cz/gitwiki/GitSvnComparsion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080612/6c91ad9e/attachment.htm 

[Buildroot] Still no answer for a contribution made in March

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 >> Hi,
 >> 
 >> >> Yea, and that's the reason why the svn-repo is completely fux0red up.
 >> 
 Thomas> I don't necessarly think so. Here, the issue is not a bottleneck at the
 Thomas> commit level, but rather a patch review bandwidth problem.
 >> 
 >> Agree - And lack of testing before stuff gets checked in. The deeper
 >> issue is that we don't do releases I guess, so there's a tension
 >> between doing development, and having something stable for actual use.
 >> 

 Ulf> Maybe we should start?

Fine by me, but that means we'll need to spend time stabilizing the
tree and make sure the packages actually work (on multiple archs). Do
you have time to help on this?

That's why I want to get buildbot up and running.

 Ulf> Other project are using "git" and is sneering at "svn".
 Ulf> Should we change?

We could, but there's no infrastructure for git on uclibc.org, and the
other uclibc.org projects use svn. I don't think it matters much, as
you can just use git-svn (like I do).

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution made in March

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> >> Hi,
> >> 
> >> >> Yea, and that's the reason why the svn-repo is completely fux0red up.
> >> 
> Thomas> I don't necessarly think so. Here, the issue is not a bottleneck at the
> Thomas> commit level, but rather a patch review bandwidth problem.
> >> 
> >> Agree - And lack of testing before stuff gets checked in. The deeper
> >> issue is that we don't do releases I guess, so there's a tension
> >> between doing development, and having something stable for actual use.
> >> 
> 
> Ulf> Maybe we should start?
> 
> Fine by me, but that means we'll need to spend time stabilizing the
> tree and make sure the packages actually work (on multiple archs). Do
> you have time to help on this?
> 

In August I think there will be time for implementation, 
but we could discuss the underlying architecture before that.

The tarball mirror server is critical.
I have been trying to convince my colleagues to set something up,
and there is some progress, since some packages are now at
http://www.atmel.no/buildroot/source/mirror/
and this could be used for testing the mirror function.

Anyone volunteering for implementing a wget script?

> That's why I want to get buildbot up and running.
> 
> Ulf> Other project are using "git" and is sneering at "svn".
> Ulf> Should we change?
> 
> We could, but there's no infrastructure for git on uclibc.org, and the
> other uclibc.org projects use svn. I don't think it matters much, as
> you can just use git-svn (like I do).
> 
> -- 
> Bye, Peter Korsgaard
>


Best Regards
Ulf Samuelsson

[Buildroot] Still no answer for a contribution made in March

[sjhill at realitydiluted.com]

> To make an informed decision, everyone ought to read this:
> 
> http://git.or.cz/gitwiki/GitSvnComparsion
>
I did. First, I would like to add a caveat to the Git page:

Git's Major Features Over Subversion
- Performance (Speed of Operation)
  Yes, as long as you have GBs of memory.

Then:

Subversion's Major Features Over Git
- Single Repository
- Access Controls
- Binary Files

These three items are important with regards to the buildroot system.
Another point brought up is that other projects like uClibc and the
like use Subversion as well, which is another reason I would like to
stay with what we have. As a maintainer and contributer, I recommend
we end this thread and get back to worry about doing releases of
buildroot.

-Steve

[Buildroot] Still no answer for a contribution made in March

[Ulf Samuelsson]

sjhill at realitydiluted.com wrote:
>> To make an informed decision, everyone ought to read this:
>> 
>> http://git.or.cz/gitwiki/GitSvnComparsion
>> 
> I did. First, I would like to add a caveat to the Git page:
> 
> Git's Major Features Over Subversion
> - Performance (Speed of Operation)
>  Yes, as long as you have GBs of memory.
> 
> Then:
> 
> Subversion's Major Features Over Git
> - Single Repository
> - Access Controls
> - Binary Files
> 
> These three items are important with regards to the buildroot system.
> Another point brought up is that other projects like uClibc and the
> like use Subversion as well, which is another reason I would like to
> stay with what we have. As a maintainer and contributer, I recommend
> we end this thread and get back to worry about doing releases of
> buildroot.
> 

OK with me.


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57


Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                 http://www.linux4sam.org/

[Buildroot] Still no answer for a contribution made in March

[Peter Korsgaard]

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

Hi,

 >> Bernard's git tree is a fork of the svn repo from some time
 >> ago. There's no official sync, but he sometimes cherrypicks commits
 >> from svn, and I sometimes do the same from his tree.
 >> 
 >> It's a pity, but has historical reasons.

 Thomas> What tree should a new user use ? The git tree doesn't seem
 Thomas> to be referenced anywhere. Isn't it possible to find a
 Thomas> solution to get back to a single officiel tree ?

Well, as a buildroot (@uclibc.org) developer, I would certainly say
use the svn tree ;)

Regarding merging the trees, that's up to Bernhard - Last time we
talked about it, he didn't seem interested though.

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution made in March

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

<stripped cc list to please mailman>

Hi,

 >> >> Agree - And lack of testing before stuff gets checked in. The deeper
 >> >> issue is that we don't do releases I guess, so there's a tension
 >> >> between doing development, and having something stable for actual use.
 >> >> 
 >> 
 Ulf> Maybe we should start?
 >> 
 >> Fine by me, but that means we'll need to spend time stabilizing the
 >> tree and make sure the packages actually work (on multiple archs). Do
 >> you have time to help on this?

 Ulf> In August I think there will be time for implementation, 
 Ulf> but we could discuss the underlying architecture before that.

Yes.

 Ulf> The tarball mirror server is critical.
 Ulf> I have been trying to convince my colleagues to set something up,
 Ulf> and there is some progress, since some packages are now at
 Ulf> http://www.atmel.no/buildroot/source/mirror/
 Ulf> and this could be used for testing the mirror function.

The support is there already (BR2_PRIMARY_SITE), but I would strongly
prefer to host it on uclibc.org instead.

Mike, would a package mirror on the uclibc.org machine be possible
(2-3GB)?

 Ulf> Anyone volunteering for implementing a wget script?

It's there already (for the new-style Makefile.autotools.in packages).

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution made in March

[Ulf Samuelsson]

> 
> Ulf> In August I think there will be time for implementation,
> Ulf> but we could discuss the underlying architecture before that.
> 
> Yes.
> 

How about this as a starting point?
The user can choose to define a "distribution" inside menuconfig.
There are a number of "known" distributions, which can be checked
for selection, or the user can supply free text.

The distribution is used to select a file containing package versions.

I.E:
BASH_VERSION:=1.10.3
LIBUSB_VERSION:=1.4.5
...
<EOF>

Any version defined here, will override the version number inside
the package makefile fragment.

All packages where this is supported, should have the patches named
<package>-<version>-<patchname>.patch[.$(ARCH)]

There should be a makefile targer to generate such version files.

As long as the package makefile does not change, you can easily 
bump package version with this method.

A user can edit a file if the default is not OK.

Best Regards
Ulf Samuelsson

[Buildroot] Still no answer for a contribution -- "me too"

[Michel]

On Wednesday 11 June 2008, Thomas Petazzoni wrote:
> Hi,
>
> On March, 12th, I sent a patch adding Thumb support for the ARM
> architecture to this list:
>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007427.html

> This absence of reaction is very frustrating for new potential
> contributors. I would like to contribute more to Buildroot, but this
> experience doesn't really encourage one in spending more time writing
> patches that will be ignored.
>
> Thomas


Hi Thomas,

It seems to be the rule more than the exception; I sent a few patches months 
ago and most of them have been ignored completely -- even the one as simple 
as adding a package (libswill, iptraf, i2c-tools)

I must admit I gave up pushing anything since. Hope you get better luck.

Michel

[Buildroot] Still no answer for a contribution -- "me too"

[Peter Korsgaard]

>>>>> "Michel" == Michel (BusError) <buildroot.atmel.com@pollet.net> writes:

Hi,

 Michel> It seems to be the rule more than the exception; I sent a few
 Michel> patches months ago and most of them have been ignored
 Michel> completely -- even the one as simple as adding a package
 Michel> (libswill, iptraf, i2c-tools)

 Michel> I must admit I gave up pushing anything since. Hope you get
 Michel> better luck.

Pity. We try, but all have limited time to work on this.

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution made in March

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

Hi,

 Mike> On Thursday 12 June 2008, Peter Korsgaard wrote:
 >> Mike, would a package mirror
 >> on the uclibc.org machine be possible (2-3GB)?

 Mike> unfortunately, no.  uclibc.org is a vm guest donated by OSU and
 Mike> i dont think it even has that much free space now.

That's what I thought ..

 Mike> you could talk to the OSU guys or perhaps kernel.org or ibiblio
 Mike> for some space ...

Ok, the issue is going to be how to push updates to them, they are
probably not particular interested doing svn up && make source kind of
stuff ..

Thanks anyway.

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution -- "me too"

[Will Newton]

On Fri, Jun 13, 2008 at 8:24 AM, Michel (BusError)
<buildroot.atmel.com@pollet.net> wrote:
> On Wednesday 11 June 2008, Thomas Petazzoni wrote:
>> Hi,
>>
>> On March, 12th, I sent a patch adding Thumb support for the ARM
>> architecture to this list:
>>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007427.html
>
>> This absence of reaction is very frustrating for new potential
>> contributors. I would like to contribute more to Buildroot, but this
>> experience doesn't really encourage one in spending more time writing
>> patches that will be ignored.
>>
>> Thomas
>
>
> Hi Thomas,
>
> It seems to be the rule more than the exception; I sent a few patches months
> ago and most of them have been ignored completely -- even the one as simple
> as adding a package (libswill, iptraf, i2c-tools)
>
> I must admit I gave up pushing anything since. Hope you get better luck.

I must confess that has been my experience too. I tried asking Erik
for commit access but again, no response. Perhaps he is working on
other projects?

It's a hard balance to strike, I don't think it's right to demand
anything of people on a volunteer led project but some of us have a
job to do and a limited amount of time to do it in.

[Buildroot] Still no answer for a contribution -- "me too"

[Ulf Samuelsson]

Will Newton wrote:
> On Fri, Jun 13, 2008 at 8:24 AM, Michel (BusError)
> <buildroot.atmel.com@pollet.net> wrote:
>> On Wednesday 11 June 2008, Thomas Petazzoni wrote:
>>> Hi,
>>> 
>>> On March, 12th, I sent a patch adding Thumb support for the ARM
>>> architecture to this list:
>>>  http://buildroot.uclibc.org/lists/buildroot/2008-March/007427.html
>> 
>>> This absence of reaction is very frustrating for new potential
>>> contributors. I would like to contribute more to Buildroot, but this
>>> experience doesn't really encourage one in spending more time
>>> writing patches that will be ignored.
>>> 
>>> Thomas
>> 
>> 
>> Hi Thomas,
>> 
>> It seems to be the rule more than the exception; I sent a few
>> patches months ago and most of them have been ignored completely --
>> even the one as simple as adding a package (libswill, iptraf,
>> i2c-tools) 
>> 
>> I must admit I gave up pushing anything since. Hope you get better
>> luck. 
> 
> I must confess that has been my experience too. I tried asking Erik
> for commit access but again, no response. Perhaps he is working on
> other projects?

He is not so active here any longer, so just keep pushing (at a moderate pace).
Took me 3-4 months to get write access.

> 
> It's a hard balance to strike, I don't think it's right to demand
> anything of people on a volunteer led project but some of us have a
> job to do and a limited amount of time to do it in.

Exactly.

> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

Best Regards
Ulf Samuelsson

[Buildroot] Still no answer for a contribution -- "me too"

[Peter Korsgaard]

>>>>> "Will" == Will Newton <will.newton@gmail.com> writes:

Hi,

 >> I must admit I gave up pushing anything since. Hope you get better luck.

 Will> I must confess that has been my experience too. I tried asking Erik
 Will> for commit access but again, no response. Perhaps he is working on
 Will> other projects?

Yes, he's not really actively involved anymore. You can ask Mike
Frysinger instead (vapier at uclibc.org).

 Will> It's a hard balance to strike, I don't think it's right to demand
 Will> anything of people on a volunteer led project but some of us have a
 Will> job to do and a limited amount of time to do it in.

I think that covers most of us.

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution made in March

[Thomas Petazzoni]

Le Thu, 12 Jun 2008 11:28:56 -0500,
sjhill at realitydiluted.com a ?crit :

> These three items are important with regards to the buildroot system.
> Another point brought up is that other projects like uClibc and the
> like use Subversion as well, which is another reason I would like to
> stay with what we have. As a maintainer and contributer, I recommend
> we end this thread and get back to worry about doing releases of
> buildroot.

As I said, I also don't think that Subversion vs. Git is the problem.
Whatever the version control system you use, you'll still have to get
the code reviewed at some point. And this what started this thread.

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080613/6168729f/attachment.pgp 

[Buildroot] Still no answer for a contribution made in March

[Peter Korsgaard]

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

Hi,

 Thomas> As I said, I also don't think that Subversion vs. Git is the
 Thomas> problem.  Whatever the version control system you use, you'll
 Thomas> still have to get the code reviewed at some point. And this
 Thomas> what started this thread.

Exactly. Want to help? ;)

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution -- "me too"

[Hamish Moffatt]

On Fri, Jun 13, 2008 at 12:07:42PM +0100, Will Newton wrote:
> I must confess that has been my experience too. I tried asking Erik
> for commit access but again, no response. Perhaps he is working on
> other projects?

I think anyone wanting write access should send some patches here first
for review. I guess you already did this -- I don't recall sorry.

Personally even though I have commit access I think it is still good to
discuss anything remotely controversial before committing it. Most
changes (new packages, package updates) don't fall in that category of
course.

> It's a hard balance to strike, I don't think it's right to demand
> anything of people on a volunteer led project but some of us have a
> job to do and a limited amount of time to do it in.

Does your job require your changes to be committed to the master
repository?

Personally I am using buildroot in a commercial product for my day job.
I am contributing everything that is relevant back to the buildroot
repository, but we have some changes specific to our application and
some proprietary packages which will never be merged. We don't expect to
be able to build our whole product directly from the
buildroot.uclibc.org repository.

I'm committing my own changes back to the master repository where
relevant, and I commit patches from this mailing list in areas that are
relevant to me and where I think I can properly review them.
Unfortunately I don't have company time to work on parts of buildroot
that fall outside these categories.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Still no answer for a contribution -- "me too"

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 Hamish> On Fri, Jun 13, 2008 at 12:07:42PM +0100, Will Newton wrote:
 >> I must confess that has been my experience too. I tried asking Erik
 >> for commit access but again, no response. Perhaps he is working on
 >> other projects?

 Hamish> I think anyone wanting write access should send some patches
 Hamish> here first for review. I guess you already did this -- I
 Hamish> don't recall sorry.

 Hamish> Personally even though I have commit access I think it is
 Hamish> still good to discuss anything remotely controversial before
 Hamish> committing it. Most changes (new packages, package updates)
 Hamish> don't fall in that category of course.

Agreed.

 Hamish> Personally I am using buildroot in a commercial product for
 Hamish> my day job.  I am contributing everything that is relevant
 Hamish> back to the buildroot repository, but we have some changes
 Hamish> specific to our application and some proprietary packages
 Hamish> which will never be merged. We don't expect to be able to
 Hamish> build our whole product directly from the
 Hamish> buildroot.uclibc.org repository.

 Hamish> I'm committing my own changes back to the master repository
 Hamish> where relevant, and I commit patches from this mailing list
 Hamish> in areas that are relevant to me and where I think I can
 Hamish> properly review them.  Unfortunately I don't have company
 Hamish> time to work on parts of buildroot that fall outside these
 Hamish> categories.

Same here.

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution -- "me too"

[Will Newton]

On Fri, Jun 13, 2008 at 1:05 PM, Hamish Moffatt <hamish@cloud.net.au> wrote:
> On Fri, Jun 13, 2008 at 12:07:42PM +0100, Will Newton wrote:
>> I must confess that has been my experience too. I tried asking Erik
>> for commit access but again, no response. Perhaps he is working on
>> other projects?
>
> I think anyone wanting write access should send some patches here first
> for review. I guess you already did this -- I don't recall sorry.

I did send patches. I took the lack of response as "everyone is too
busy right now", and because in our company we've been using and
patching buildroot for a few years I though it reasonable to offer
some assistance in that regard.

> Personally even though I have commit access I think it is still good to
> discuss anything remotely controversial before committing it. Most
> changes (new packages, package updates) don't fall in that category of
> course.

Patch review is certainly a good thing.

>> It's a hard balance to strike, I don't think it's right to demand
>> anything of people on a volunteer led project but some of us have a
>> job to do and a limited amount of time to do it in.
>
> Does your job require your changes to be committed to the master
> repository?
>
> Personally I am using buildroot in a commercial product for my day job.
> I am contributing everything that is relevant back to the buildroot
> repository, but we have some changes specific to our application and
> some proprietary packages which will never be merged. We don't expect to
> be able to build our whole product directly from the
> buildroot.uclibc.org repository.
>
> I'm committing my own changes back to the master repository where
> relevant, and I commit patches from this mailing list in areas that are
> relevant to me and where I think I can properly review them.
> Unfortunately I don't have company time to work on parts of buildroot
> that fall outside these categories.

I'm in a similar situation. We have a snapshot of buildroot that is
patched for our needs. I would like to be able to contribute as much
as possible back however, because it makes my life easier and helps
the project as a whole. For example, some time ago I wrote some
makefiles for glib 2.x when at the time there was only glib 1.2
support in buildroot. I kept meaning to push these back upstream but
never got round to it. Someone else did however, which left me with a
difficult merge to do and duplicated effort.

[Buildroot] Still no answer for a contribution -- "me too"

[Brian Beattie]

On Fri, 2008-06-13 at 22:05 +1000, Hamish Moffatt wrote:

> Personally even though I have commit access I think it is still good to
> discuss anything remotely controversial before committing it. Most
> changes (new packages, package updates) don't fall in that category of
> course.

I have a change I'd love to discuss.  I have asked twice now about the
correct place to add support for a new board and have received no
response whatever.

This makes me sceptical of even trying to submit a patch.

try #3, I would like to add support for a board from KwikByte based on
the at91rm9200 processor. should I add it to target/device/Atmel or
should I create a new directory target/device/KwikByte or some other
location.

I have a patch for the first option.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting a bad thing?

Brian Beattie   LFS12947 | "Honor isn't about making the right choices.
beattie at beattie-home.net | It's about dealing with the consequences."
www.beattie-home.net     | -- Midori Koto

[Buildroot] Still no answer for a contribution made in March

[Thomas Petazzoni]

Le Fri, 13 Jun 2008 14:00:18 +0200,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

>  Thomas> As I said, I also don't think that Subversion vs. Git is the
>  Thomas> problem.  Whatever the version control system you use, you'll
>  Thomas> still have to get the code reviewed at some point. And this
>  Thomas> what started this thread.
> 
> Exactly. Want to help? ;)

Sure.

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080613/b8be3f04/attachment.pgp 

[Buildroot] Still no answer for a contribution -- "me too"

[Peter Korsgaard]

>>>>> "Brian" == Brian Beattie <beattie@beattie-home.net> writes:

Hi,

 Brian> try #3, I would like to add support for a board from KwikByte based on
 Brian> the at91rm9200 processor. should I add it to target/device/Atmel or
 Brian> should I create a new directory target/device/KwikByte or some other
 Brian> location.

Both Ulf and I answered that target/device/KwikByte was the way to
go..

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution -- "me too"

[Brian Beattie]

On Fri, 2008-06-13 at 14:51 +0200, Peter Korsgaard wrote:
> >>>>> "Brian" == Brian Beattie <beattie@beattie-home.net> writes:
> 
> Hi,
> 
>  Brian> try #3, I would like to add support for a board from KwikByte based on
>  Brian> the at91rm9200 processor. should I add it to target/device/Atmel or
>  Brian> should I create a new directory target/device/KwikByte or some other
>  Brian> location.
> 
> Both Ulf and I answered that target/device/KwikByte was the way to
> go..
> 

Thanks for the response, I'll rework the patch.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting a bad thing?

Brian Beattie   LFS12947 | "Honor isn't about making the right choices.
beattie at beattie-home.net | It's about dealing with the consequences."
www.beattie-home.net     | -- Midori Koto

[Buildroot] Still no answer for a contribution -- "me too"

[Ulf Samuelsson]

Hamish Moffatt wrote:
> On Fri, Jun 13, 2008 at 12:07:42PM +0100, Will Newton wrote:
>> I must confess that has been my experience too. I tried asking Erik
>> for commit access but again, no response. Perhaps he is working on
>> other projects?
> 
> I think anyone wanting write access should send some patches here
> first for review. I guess you already did this -- I don't recall
> sorry. 
> 
> Personally even though I have commit access I think it is still good
> to discuss anything remotely controversial before committing it. Most
> changes (new packages, package updates) don't fall in that category of
> course.
> 
>> It's a hard balance to strike, I don't think it's right to demand
>> anything of people on a volunteer led project but some of us have a
>> job to do and a limited amount of time to do it in.
> 
> Does your job require your changes to be committed to the master
> repository?
> 
> Personally I am using buildroot in a commercial product for my day
> job. I am contributing everything that is relevant back to the
> buildroot repository, but we have some changes specific to our
> application and some proprietary packages which will never be merged.
> We don't expect to be able to build our whole product directly from
> the buildroot.uclibc.org repository.

I think this is fairly common.
That is why I proposed the "local" directory,
where the location can be defined as a shell environment variable.

BR2_LOCAL or something.

By putting your packages here, you should be able to download
a new svn and use it without modifications.

It was a lot of protests at that time, and it was never fully implemented.

The make saveconfig/getconfig uses the local directory.

I think that it would be easy to expand to have packages in this directory as well.

> 
> I'm committing my own changes back to the master repository where
> relevant, and I commit patches from this mailing list in areas that
> are relevant to me and where I think I can properly review them.
> Unfortunately I don't have company time to work on parts of buildroot
> that fall outside these categories.
> 
> Hamish

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57


Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                 http://www.linux4sam.org/

[Buildroot] Still no answer for a contribution -- "me too"

[Ulf Samuelsson]

Brian Beattie wrote:
> On Fri, 2008-06-13 at 22:05 +1000, Hamish Moffatt wrote:
> 
>> Personally even though I have commit access I think it is still good
>> to discuss anything remotely controversial before committing it. Most
>> changes (new packages, package updates) don't fall in that category
>> of course.
> 
> I have a change I'd love to discuss.  I have asked twice now about the
> correct place to add support for a new board and have received no
> response whatever.
> 
> This makes me sceptical of even trying to submit a patch.
> 
> try #3, I would like to add support for a board from KwikByte based on
> the at91rm9200 processor. should I add it to target/device/Atmel or
> should I create a new directory target/device/KwikByte or some other
> location.
> 
> I have a patch for the first option.

I think we already replied that it should go into target/device/KwikByte.



Best Regards
Ulf Samuelsson

[Buildroot] Still no answer for a contribution -- "me too"

[Hamish Moffatt]

On Fri, Jun 13, 2008 at 05:44:44AM -0700, Brian Beattie wrote:
> On Fri, 2008-06-13 at 22:05 +1000, Hamish Moffatt wrote:
> 
> > Personally even though I have commit access I think it is still good to
> > discuss anything remotely controversial before committing it. Most
> > changes (new packages, package updates) don't fall in that category of
> > course.
> 
> I have a change I'd love to discuss.  I have asked twice now about the
> correct place to add support for a new board and have received no
> response whatever.
> 
> This makes me sceptical of even trying to submit a patch.
> 
> try #3, I would like to add support for a board from KwikByte based on
> the at91rm9200 processor. should I add it to target/device/Atmel or
> should I create a new directory target/device/KwikByte or some other
> location.
> 
> I have a patch for the first option.

I don't know the answer.
Is the board made by Atmel or some other vendor? Are the other boards in
target/device/Atmel all made by Atmel or a mix of vendors? I guess it
should follow the lead of the other boards.

The Atmel guys seem to be suggesting it should go in
target/device/KwikByte.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Still no answer for a contribution -- "me too"

[Hamish Moffatt]

On Fri, Jun 13, 2008 at 03:33:10PM +0200, Ulf Samuelsson wrote:
> Hamish Moffatt wrote:
> > Personally I am using buildroot in a commercial product for my day
> > job. I am contributing everything that is relevant back to the
> > buildroot repository, but we have some changes specific to our
> > application and some proprietary packages which will never be merged.
> > We don't expect to be able to build our whole product directly from
> > the buildroot.uclibc.org repository.
> 
> I think this is fairly common.
> That is why I proposed the "local" directory,
> where the location can be defined as a shell environment variable.
> 
> BR2_LOCAL or something.
> 
> By putting your packages here, you should be able to download
> a new svn and use it without modifications.
> 
> It was a lot of protests at that time, and it was never fully implemented.
> 
> The make saveconfig/getconfig uses the local directory.
> 
> I think that it would be easy to expand to have packages in this directory as well.

I am using several boards defined in local/<project> already, this
system works very well for me. 

So far we have added our proprietary packages in a new top-level
directory and editted the main makefiles to include it. I think it would
be useful to include this structure in vanilla buildroot though - I
prefer to minimise my changes to the standard makefiles.

I'd prefer not to mix my packages in with the existing local/ directory.
It could either be in a user-defined location as you suggest or just a
new vendor/ directory or similar.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Still no answer for a contribution -- "me too"

[Knut-Håvard Aksnes]

Hamish Moffatt wrote:
> On Fri, Jun 13, 2008 at 12:07:42PM +0100, Will Newton wrote:
>   
>> I must confess that has been my experience too. I tried asking Erik
>> for commit access but again, no response. Perhaps he is working on
>> other projects?
>>     
>
> I think anyone wanting write access should send some patches here first
> for review. I guess you already did this -- I don't recall sorry.
>
> Personally even though I have commit access I think it is still good to
> discuss anything remotely controversial before committing it. Most
> changes (new packages, package updates) don't fall in that category of
> course.
>
>   
>> It's a hard balance to strike, I don't think it's right to demand
>> anything of people on a volunteer led project but some of us have a
>> job to do and a limited amount of time to do it in.
>>     
>
> Does your job require your changes to be committed to the master
> repository?
>
> Personally I am using buildroot in a commercial product for my day job.
> I am contributing everything that is relevant back to the buildroot
> repository, but we have some changes specific to our application and
> some proprietary packages which will never be merged. We don't expect to
> be able to build our whole product directly from the
> buildroot.uclibc.org repository.
>
> I'm committing my own changes back to the master repository where
> relevant, and I commit patches from this mailing list in areas that are
> relevant to me and where I think I can properly review them.
> Unfortunately I don't have company time to work on parts of buildroot
> that fall outside these categories.
>   
I am in a similar situation to many of the other contributors to this 
list. I am working as consultant mostly for a local customer. As long as 
my bug reports and patches are related to
the product development I am doing I can spend some paid time for the 
common good. My last project was porting of a customer specific firewall 
from a RedHat derivative to a buildroot based platform. My current 
project is an attempt to port firefox-3.0 to  DirectFB on a customer 
specific card. The processor on this card is  a mipsel based "system on 
a chip".

For both these projects parts of what I do is of general interest and 
fixes should be done in buildroot, other parts are customer specific and 
will probably of little interest for most other companies.

What's important for me is speed and quality :-)

Personally I would like to have subversion commit access to be able to 
speed up obvious bug-fixes, but I will at the same time try to avoid 
making a mess of the repository.
Obvious fixes, like missing dependencies or faulty configuration 
parameters can be fixed directly on trunk if they are well tested 
locally and unlikely to cause regressions in other builds. More tricky 
or larger fixes, like introducing new packages or upgrading major 
versions of several interdependent packages at the same time can be done 
in their own feature branches. Anybody with access to the repository can 
test and review these changes. If the fix(es) are accepted the feature 
branch is merged back into trunk and deleted. Creating merging and 
deleting branches are cheap operations in subversion.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: kna.vcf
Type: text/x-vcard
Size: 507 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080613/7e248ed0/attachment.vcf 

[Buildroot] Still no answer for a contribution -- "me too"

[Thiago A. Corrêa]

> I am in a similar situation to many of the other contributors to this list.
> I am working as consultant mostly for a local customer. As long as my bug
> reports and patches are related to
> the product development I am doing I can spend some paid time for the common
> good. My last project was porting of a customer specific firewall from a
> RedHat derivative to a buildroot based platform. My current project is an
> attempt to port firefox-3.0 to  DirectFB on a customer specific card. The
> processor on this card is  a mipsel based "system on a chip".

A bit off-topic, but did you consider Webkit? it's working in
buildroot, and it passes 97% ACID3 test, making it in that respect
better than firefox. And it should consume less resources (memory and
CPU cycles). The downside is lack of Flash, but I guess there is no
flash for linux based MIPs archs.

> For both these projects parts of what I do is of general interest and fixes
> should be done in buildroot, other parts are customer specific and will
> probably of little interest for most other companies.

Being able to have your fixes in mainstream is a win-win thing to do.
Takes out some of the maintenance burden of forking and you get other
people's fixes. For buildroot, it gets better in general, receiving
fixes, and most importantly, more eyeballs.

> Personally I would like to have subversion commit access to be able to speed
> up obvious bug-fixes, but I will at the same time try to avoid making a mess
> of the repository.

This is my third attempt, I was able to talk to Mike, and seams that
being vouched for is all that is required. Which would imply getting
some patches sent before.

> Obvious fixes, like missing dependencies or faulty configuration parameters
> can be fixed directly on trunk if they are well tested locally and unlikely
> to cause regressions in other builds. More tricky or larger fixes, like
> introducing new packages or upgrading major versions of several
> interdependent packages at the same time can be done in their own feature
> branches. Anybody with access to the repository can test and review these
> changes. If the fix(es) are accepted the feature branch is merged back into
> trunk and deleted. Creating merging and deleting branches are cheap
> operations in subversion.
>

Yes, that's one of the things that would be greatly beneficial to the
project, along with having releases and perhaps a continal building
system. I tried once to get builtbot to work with buildroot, even
asked for some help here but no one was interested in replying. :(

Kind Regards,
   Thiago A. Correa

[Buildroot] Still no answer for a contribution -- "me too"

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

Hi,

 Thiago> This is my third attempt, I was able to talk to Mike, and
 Thiago> seams that being vouched for is all that is required. Which
 Thiago> would imply getting some patches sent before.

CC me on the mail to Mike and I'll ack it.

 Thiago> Yes, that's one of the things that would be greatly
 Thiago> beneficial to the project, along with having releases and
 Thiago> perhaps a continal building system. I tried once to get
 Thiago> builtbot to work with buildroot, even asked for some help
 Thiago> here but no one was interested in replying. :(

I have it running internally at work with the configs we use. I'm
working on getting an official instance up and running with a bigger
coverage soon.

-- 
Bye, Peter Korsgaard

[Buildroot] Still no answer for a contribution -- "me too"

[Thiago A. Corrêa]

On Fri, Jun 13, 2008 at 5:04 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>  Thiago> Yes, that's one of the things that would be greatly
>  Thiago> beneficial to the project, along with having releases and
>  Thiago> perhaps a continal building system. I tried once to get
>  Thiago> builtbot to work with buildroot, even asked for some help
>  Thiago> here but no one was interested in replying. :(
>
> I have it running internally at work with the configs we use. I'm
> working on getting an official instance up and running with a bigger
> coverage soon.
>

That's good news. You can count me in for a bot if it's distributed
like builtbot.

[Buildroot] Still no answer for a contribution -- "me too"

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

Hi,

 >> I have it running internally at work with the configs we use. I'm
 >> working on getting an official instance up and running with a bigger
 >> coverage soon.
 >> 

 Thiago> That's good news. You can count me in for a bot if it's distributed
 Thiago> like builtbot.

Thanks. My current plan is to use a machine from the gcc cluster:

http://gcc.gnu.org/wiki/CompileFarm

-- 
Bye, Peter Korsgaard