[Gta04-owner] Status PCBs / Kernel development

[Dr. H. Nikolaus Schaller]

Am 01.04.2011 um 21:47 schrieb Lars-Peter Clausen:

> On 04/01/2011 08:03 AM, Dr. H. Nikolaus Schaller wrote:
>> 
>> Am 31.03.2011 um 14:05 schrieb Radek Polak:
>> 
>>> On Thursday 31 March 2011 09:27:00 Dr. H. Nikolaus Schaller wrote:
>>> 
>>>> Is someone of you very experienced in that type of work and can help to set
>>>> up how to work together and organize all this, so that we finally get to
>>>> the goal of a mainstreamed GTA04 kernel?
>>> 
>>> Lars-Peter Clausen seems to be the most competent person for GTA02 kernel 
>>> development. He actually sent most of GTA02 hardware upstream - you can search 
>>> vanilla log. He also did awesome work and rewrote/made maintainable patches 
>>> from andy-tracking mess. I wonder if he is interested in GTA04.
>> 
>> I don't know but I have put him on CC so he may answer if he likes.
>> 
> 
> I've followed the GTA04 loosely so far and don't have a GTA04 either (yet).

Well, we are still on the last 100meters to build the first batch of hardware...

> 
>>> 
>>> Also distro maintainers will probably take care of keeping/backporting patches 
>>> that they want in their git's. Common repository for all distros does not work 
>>> well because some distro is concentrating on stable release while others are 
>>> in experimental stage.
>> 
>> Well, my idea is that we (GTA04 project) should run some authoritative, bleeding
>> edge git (connected to HW releases e.g. to fix issues and variants) and distros
>> (SHR, QtMoko, ...) can take the unstable or stable versions as they prefer. Or they can
>> wait until we have pushed our patches upstream and they can take kernel.org.
>> 
>> I think this is the same way as BeagleBoard and OpenPandora are working.
>> 
>> In the long run, we may get a working kernel (lagging a little behind our own
>> developments) into Ubuntu & Debian.
>> 
>> Nikolaus
> 
> In my opinion the model used for the current GTA02 kernel development worked
> out quite nicely:
> * Keep each driver in a separate branch. Have one branch where you merge them
> all, which can be used by distros.

Ok, this should IMHO be the 'master' branch. Right?

> * Don't 'track' linus, branch of at stable releases. You don't want the latest
> and greatest bugs from -rc1 stalling your development. If you need a certain
> patch you can always cherry-pick it.
> * Rebase your branches instead of merging, so the changes won't get lost in a
> endless commit-tree labyrinth
> * Squash fixes into the 'real' patch when rebasing the branch, so you can keep
> a small and manageable set of commits/patches.
> * Don't necessarily wait until everything is done. If a certain driver is
> ready, try to send it upstream.

Ok.

This would mean we simply start over with 2.6.38 (final) from git and start
adding/fixing the already existing drivers.

When 2.6.39 final comes out, we will do the rebase. AFAIK it did take approx.
2 months from 2.6.38-rc1 to final so we can expect this by June.

Nikolaus