Upstreaming (offer to help)

[Lars-Peter Clausen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

Sveinung Kvilhaugsvik wrote:
> 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.

Those that are believed to have a good enough quality to go in but
haven't been
sent yet:
No driver in this category

those that aren't there yet (if for example user space interfaces may
change)
but have someone working on bringing them closer:
That would be the powermanagement drivers and glamo+jbt

those drivers that duplicate upstream drivers:
Thats bq27000, but I have WIP for merging it with the bq27x00 driver.

And a fifth category: Those which are never going to be upstream: AR6000
>
> 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.
>
Well, the only driver that would qualify for staging is the glamo
driver. But I'm not sure if it really makes sense to put it into
staging. The only known HW platform using the glamo is the Freerunner.
And the current distributions for the Freerunner build the kernel from
the openmoko git kernel tree anyway.
On the other hand having to send each patch through staging might slow
things down.

> 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
>

Thanks for your help.

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwREJ0ACgkQBX4mSR26RiOHXACfYadho1r3pnu7H2FBfp4DFi5O
mLgAnR83lm2vYPzaHC7jH6vfRXJjywfu
=LWzM
-----END PGP SIGNATURE-----