Upstreaming (offer to help)

Sveinung Kvilhaugsvik sveinung84 at users.sourceforge.net
Thu Jun 10 16:18:01 CEST 2010


Hello

What is holding the drivers for the Freerunner back from being merged
upstream? Can I do something to help? Following is a suggestion for
what I could do. (Please be aware that English is not my native
language. So if something is unclear, impossible to understand, easy
to misunderstand or written in an insulting tone please ask me to
clarify)

First some background on my thinking. I think the drivers that still
are missing can be divided in four classes: Those that are believed to
have a good enough quality to go in but haven't been sent yet, those
that aren't there yet (if for example user space interfaces may
change) but have someone working on bringing them closer to the
quality needed to get them into the stable parts of Linux, those that
aren't there and aren't being worked on and those drivers that
duplicate upstream drivers. I don't know what driver is in what class
since thing may have changes since [1]. I know that some drivers have
been merged and others have had alternatives merged since then but I'm
unsure about the rest.

If my understanding of the process for Linux development is correct
the situation is this: Drivers that are believed to be in the first
class could go right into the stable parts of the Linux kernel. On the
other hand they could have issues and it could take time to get the
maintainers of the correct sub systems to review them. They could also
go into staging with an "ask for feedback" in the todo. Drivers in the
second category could only go into staging. (With issues that needs to
be fixed in the todo) Drivers in the third category can't even go into
staging unless they're already in widespread use or someone is willing
to work on them. Drivers in staging can be thrown out if they don't
make progress but unlike staying in a separate tree they will get more
upstream attention. The attention means more people working to clean
them up, help to change them when API's changes, etc.

Since my C currently isn't the best I don't think I can help with
drivers that don't have others working on them as well. But I realize
that in addition to technical issues there are also other issues that
may delay submitting code upstreams like getting the author
information right. One thing I could do is to try to get patches
containing the drivers and the authorship information that are in the
second class or in the first class (but not expected to be submitted
before after 2.6.36) into staging. Before sending them I would check
Andy-tracking, the 2.6.3x series on git.openmoko.org, the source code
and other sources for authorship information (if someone could point
them out to me) to get the authorship correct. Then I would ask on
this list if anyone feels left out just to be sure before sending
them. If they were accepted into staging I could post patches for the
trees on git.openmoko.org to move the code into the staging directory
there as well to make patches easier to port between them and the
upstream tree. I would also try to forward patches committed there to
staging if the author doesn't. If other issues than getting authorship
right and the act of sending patches are in the way of getting them
closer to upstream I could try to solve them if they are pointed out
to me. For example I think that my C is good enough to convert drivers
that include firmware to use firmware loader to avoid legal issues if
a driver has that kind of problems.

If you think this sounds like a good idea please give me a hint about
what driver(s) I could start with. If not please tell me why. If you
have other ideas on how I can help make the drivers move upstream (or
closer to upstream like staging) faster please tell me so I can
consider it.

Sincerely
Sveinung Kvilhaugsvik

[1] http://lists.openmoko.org/pipermail/openmoko-kernel/2009-July/010379.html



More information about the openmoko-kernel mailing list