2.6.25 / mainline tracking effort

[Andy Green]

On Thursday 17 April 2008 04:03:51 pm Harald Welte wrote:
> Hi Andy!
>
> Since 2.6.25 was released today, I am about to give the patch submission
> to the mainline kernel another round.  I really want to get the core
> patches for GTA01 and possibly also GTA02 into the kernel this time
> (pcf50606/pcf50633, machine support for gta01/gta02, backlight driver,
> led, etc.)  while keeping the more controversial stuff like fiq for a
> bit later to increase the probability that the 2.6.27 will at least boot
> on the systems.

Wah well this is an unexpected nice surprise!  I just upleveled the tracking 
thing to 2.6.25 official here earlier.

Felipe Balbi is also looking at doing some work on getting it upstream, I cc 
him.

> I'm not too worried about a minor bug here or there still in the code,
> since we can get bugfixes in at any later point, too.
>
> So what I'd like to do is to manually review every individual patch, do
> another checkpatch.pl round, and then submit it like I did before.

Sure.

> However, since SVN is no longer in use, I am facing the problem that the
> individual commits are visible in the mokopatches-tracking tree, but
> - correct me if I'm wrong - that your stgit tree is private and not
> public.

Well, there is no problem with privacy of trees, I blow my actual stgit 
branches up on to git wholesale with every update.  The only things I have 
kicking around that aren't visible are Cesar's cpufreq patches which are in 
the my stack but above what is actually applied.  Other than that, my stgit 
branches are actually exactly public in git.

> So what I'll probably be doing is to once again extract the patches from
> the mokopatches-tracking into something like a quilt series and then
> submit that.
>
> Do you see any more optimal workflow?

Hum.  I wish I understood more about advanced use of git but I don't.

The workflow in what we discuss is really dictated by what you need to achieve 
to succeed to pass things upstream, less by our side I think.

One way to come at it is that we don't react to your changes until we find 
them coming in from upstream, then we are insulated from any interative 
process about changes -> NAK change it to this -> more changes -> ACK, we 
only see what was ACKed and deal with breakage then -- it's a stone cold fact 
then because it actually is upstream.

I wonder if maybe Felipe and yourself could cooperate to reduce the workload, 
and then if it can be done in a git branch to ease that.  For example, if 
upstream are going to talk about regulator API for pcf50606/33 then this is a 
bit chunk of work.

So I don't have much of a better idea :-)  Hey but this is good news all 
around I think, thanks for considering this effort.

-Andy