[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