[Buildroot] RFC: patch collaboration

Robert Schwebel r.schwebel at pengutronix.de
Fri Oct 30 21:14:52 UTC 2009


Hi Peter, Thomas & buildroot crew,

At ELC-E, we discussed how we could improve the collaboration between
the cross build systems out there. Although there are big differences
in what kind of tools people use, there is one thing that all cross
build systems have in common: patches for upstream packets.

What people usually do when starting a new packet which doesn't build
out of the box is looking around if oe, buildroot, ptxdist, t2, ... has
a patch, copy it, or, if not, invest more or less time to fix (or hack
around) the upstream issue. Then patches go into the build systems and
bit rot there :-)

I'm wondering if there is interest in more collaboration wrt. bringing
cross development paches upstream; one effort we started after FOSDEM
this year is the send-patches.org project, mainly by creating the
crossdev at send-patches.org mailing list. However, I suppose we should
think about what we could do to increase the activities.

The main concern of the ptxdist maintainers with simply taking patches
from other build systems is patch quality; our rules are:

- patches have to be in the canonical patch format, as known from linux
- proper Signed-off-by: lines
- patches should be made with upstream in mind, i.e. "correct" fixes
  instead of quick hacks; if we really need hacks, they should be
  clearly marked as "not for upstream".
- modify autotool files separately from their autogenerated files

What do you think? Should we try to create a new patch stack which
follows these rules, in order to lower the ammount of duplicate work? At
least for us, this would be very interesting.

Cheers,
Robert (ptxdist team)
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


More information about the buildroot mailing list