Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Samuel Robb <sam@oneparticularharbor.net>]

On Thu, 2008-06-12 at 16:02 -0600, Jim Freeman wrote:
> Most vendors these days have finally gotten the clue that sources/changes
> have to be made available to downstream requesters, but far fewer
> are sufficiently self-enlightened to figure out that changes need to
> be accepted upstream for them to keep flowing back.  And to make that
> happen, vendors have to take on substantially higher overhead to win
> acceptance of patches/changes upstream, an undertaking often sadly
> fraught with hassle, uncertainty, and even peril.  So they mostly
> don't bother.  To their (and their customers, and our) long-term
> detriment.

So - how do you reduce that overhead, then?  Keep in mind that while
pushing kernel changes upstream is significant, there are other projects
as well.  Most embedded developers are working not just with the kernel,
but with a constellation of packages related to their projects.  In
order to "push changes upstream", they may end up having to work with
several different communities... each with their own model of
interaction, their own model of patch submission, and their own release
schedules.  Figuring out how to deal with just one community (kernel)
doesn't help them in dealing with another (say, samba).

When you have a one- or two-line fix, and face Yet Another round of
finding the right mailing list, identifying the right maintainers,
figuring out the right way to submit a bug and a patch, and then have to
spend the next 3 weeks explaining how no, you're not interested in being
the PPC maintainer for libfoo... is it any wonder that developers (not
to mention their management) eventually just gives up on the idea of
"giving back to the community?"

One possible solution would be to provide a clearing house for these
sorts of changes, maybe under the auspices of CELF or a similar
organization.  Instead of submitting patches to individual projects,
submit them to the clearing house, and let interested individuals either
gather together and push related patches upstream in individual
projects, or give project maintainers a place to go and find embedded
systems patches related to their projects.

-Samrobb