Balaji Rao is joining Openmoko as a new kernel developer who will help with the upstream merge. Welcome, Balaji !
Wolfgang has asked me to write down what tasks need to be done in order to tackle this, and where Balaji can help. Here's the plan (slightly edited from the draft I sent in private mail before): I see basically the following phases for pushing things upstream: - review and clean them up to the point that we're happy with them - separate the parts that aren't suitable yet for upstream, such as WLAN or our "private" USB IDs - break the rest into manageable pieces - submit them for review - handle the rejects, possibly moving things into the "later" pile - resubmit for review, if needed - submit for inclusion - handle any fallout, e.g., if problems are discovered after a patch has been accepted Not everything needs all this. E.g., a simple fix for an upstream bug can skip right to final submission, and there are some changes that can be handled apart from the rest. Larger changes also need synchronizing with upstream's merge window. The cleanup would also be an excellent opportunity to visit all our code and to form a battle plan for the later stages. I currently see the following tasks there: - make sure we use consistent naming, e.g., Openmoko-specific things shouldn't be named s3c_something and vice versa. There's a number of bad examples in arch/arm/mach-s3c2440/mach-gta02.c, and I'm sure there are plenty more in our tree. - some of our code has grown a bit complex and could benefit from refactoring. In particular, large functions should be broken down into smaller pieces. - check that the logic of the code makes sense. We will get asked to explain how and why something works, so we better have our homework in good shape. This is also an opportunity to look for race conditions. - make sure the code still compiles if individual config options are disables or enable. I'd suggest to try all our options, none of our options, walk through the list of out options and enable/disable them one at a time, and finally try random combinations. This should be automated, of course. - we also have some contamination of platform-specific code in platform-independent drivers. Sometimes, this is covered up by platform callbacks, but that's cheating :) Fixing those problems is more demanding than the other items I've listed. - mach-gta02.c wants breaking down into smaller pieces, probably into a new subdirectory. This would be an apparently unprecedented exercise, so we have to ask on linux-arm whether they'd welcome the idea, and what naming conventions to use. Then we'll have to turn our chain of git commits into sequential topic patches. This is the hard part, particularly since we have to expect that there will be a lot of small issues with the first patches we submit, and we'll have to keep these topic patches alive for a while. This is the task everybody is scared of, because it's such a lot of code. None of the kernel developers I've talked to about this has had any more encouring advice than to wish us luck :-) My idea is to semi-automate this task: define which files should go into which topic patch, and then a program can find out what sort of conflicts this would cause. Then these conflicts can be removed by specifying more details and/or reverting patches, separating them, and checking them in again. That way, we can put all the cleanup and fixes into git as usual, and just generate a new set of topic patches in the end. No need to branch and maintain parallel trees with dozen or even hundreds of shared commits for months. I've started to work a bit on that program that can generate topic patches directly from our repository, but I realized later that I tried to be too clever about how this tracked changes and that my algorithm wouldn't work. (I tried to make it track the history of every single line, but there are too many ambiguities to handle.) So I'll have to do this again. It's been mainly a pencil and paper exercise so far anyway. My suggestion would be that you start with the internal cleanup. When I'm done with WLAN, I'll write my new and improved patch maker, and then we can synchronize and prepare for the big push. The cleanup tasks I've outlined above can be done in pretty much any order and they can of course also be combined in any way you like. Does that sound good ? - Werner
