[Buildroot] [PATCH 0/3] Support for out-of-tree Buildroot customization

Thomas De Schampheleire patrickdepinguin at gmail.com
Fri Sep 13 07:35:04 UTC 2013


Hi Thomas,

On Thu, Sep 12, 2013 at 8:21 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Thu, 12 Sep 2013 09:54:56 +0200, Thomas De Schampheleire wrote:
>

>> The upstreaming work is currently done by one person (me) and this is
>> clearly the weak point. If I stop paying attention to upstreaming, or
>> to keeping the changes we make upstreamable, the delta between our
>> development repo and mainline buildroot becomes so large that it is a
>> nightmare to keep up with newer releases.
>
> Do you think there is something we can do at the Buildroot level to
> ease this process?

I don't think there is much to do about that. The buildroot community
is very open and active, so there is no real reason why others
couldn't do what I do. The 'time' aspect is the only hurdle I have
experienced in the past, in two ways:
1. upstreaming changes requires effort and time from the developer
side, in order to prepare the patch in the first place, send it, and
update after comments. All this in several cycles depending on the
comments. In a typical company mindset, upstreaming is not a first
priority, so these tasks go in-between other stuff.
Except for encouraging companies and other forks to upstream their
changes as much as possible, there is little the buildroot community
can do here.

2. sometimes patches get very little, if any, response. Especially in
the beginning of my contributions, this was very frustrating. I pinged
patches, re-sent them, even multiple times, and still not even a
comment was given. I can imagine that not everyone continues trying,
and several people will just give up, tagging the buildroot community
as 'not accepting patches'.
The situation has certainly improved since then, I think: the
introduction of patchwork helps keeping track of open patches, and
although I have not kept numbers I think the community certainly has
grown, and there are now several more people systematically reviewing
patches so that the burden does not fall entirely on Peter and
yourself.
I think we should still keep an eye on this though. I think it still
happens that patches are sent by 'new' people in the community, and
there is little or no reaction. Sometimes the patch does not really
fit in our general belief of how buildroot should be, but maybe we
don't always dare to say it. Or sometimes the patch is so specific
that it is hard to  give a good review, so one waits until someone
else with more experience in that area gives some comments, which may
never happen.
Ideally, patches should stay no longer than a fixed amount of time in
patchwork. Either the patch is given some comments and we
wait/encourage for the submitter to send an updated version, or we
reject the patch with some explanation, or we ask more details so we
can either accept/reject it with more background. This may not be
feasible for all patches. Sometimes there is simply no-one who really
needs the extra feature/fix except the submitter himself, but that is
not necessarily a reason not to accept the patch.

[..]
>
> Thanks a lot for this write-up. I think we should keep it somewhere in
> a section of the manual.

Thanks. I'm adding Samuel on this one.
If we add this to the manual, then maybe we should add some other ways
in which buildroot can be used: a number of recipes that work and from
which beginning users can choose or get ideas from.

Best regards,
Thomas



More information about the buildroot mailing list