new kernel ... / another try at getting anything upstream

[Werner Almesberger]

Andy Green wrote:
> We shouldn't move to the tracking branch since it just follows upstream
> HEAD all the time, that's what it is for to create patches that allow us
> to follow along.

Ah, sorry, wrong branch then :-)

> Soon we need to jump to 2.6.26, which I also have had ready for some
> time in git, unless we tie it to Holger's hw ECC NAND patches that are
> incompatible with NOR U-Boot

Hmm yes, what do we do with the ECC ? I see three possibilities:

- change kernel and NAND u-boot, and tell people to use NOR u-boot
  only to load u-boot into RAM

- idem, but make NAND u-boot auto-detect the ECC algorithm, and
  tell people to use NOR u-boot for anything but rootfs or kernel

- switch to NAND qi

What do you think ?

> So I intend to sort that and then propose we shift to 2.6.26.

Perfect ! By the way, now that you mentioned suspend/resume, what's
the plan with resume dependencies ? Is this something you want to
propose as mainline functionality ? Or do you expect it to vanish
in the course of the suspend/resume cleanup ?

> I don't see we need to freeze development.  You can pick a day to take
> our tree and do the diff, and aim to get that upstream.

Ah, but then you'd have a diverging branch that will take months
to get merged again, and where lots of changes will happen in the
branch and in its parent.

> Anything you got upstream based on "the reference day", say it was
> pcf50633 from a week ago :-), the patches on stable-tracking since the
> reference day that are relevant can just be sent upstream as well.

That would be *very* confusing for reviewers. The general rule is to
submit new things in their final state, not with lots of "internal"
deltas. Also, some of the changes would conflict with the linear
topic patch, returning us to square one.

That's why I want to make the process of creating topic patches as
lightweight as humanly possible - if anything changes, you just make
a new and up to date set. If the change caused problems, you're told
upfront and you only have to solve that one problem. If your
attempted fix broke something else, you're told as well. If you make
a mistake in your structuring of the topic patches, you fix that
mistake but you won't get a gazillion of failed patches as a
consequence. And you can fix the mistake long after you've made it.

Our topic patches with quilt didn't have that flexibility. Any
mistake in the structuring was hard to solve, which led to the
accumulation of flaws you noted yourself.

(That isn't to say that quilt or similar would be bad tools. They're
just troublesome if used in that modus operandi.)

> Anyway as I said six months ago, the main thing is that this belated
> upstream effort should not trash up current development.

That's why I'm suggesting to do a gradual cleanup. I don't think
Holger's janitorial activities caused much of an upset, so this
seems to fit nicely with day to day work. And if any change should
be really troublesome, we should sort this out before pushing it
upstream, rather than dumping it into your lap as a messy surprise
falling from the sky months later :-)

- Werner