new kernel ... / meaning of stable-tracking

[Werner Almesberger]

Andy Green wrote:
> Qi lacks any ECC support right now and going forward it looks like we
> don't even need NAND support in it.  So we would be adding it just for this.

That's true, yes. Even if abandoning the NAND as much as possible,
we'd still need ECC support to reliably load qi from NAND itself.

We could avoid this if the probability to hit a page with only a
single-bit error is very low when loading qi, but I'm not sure
this is a good assumption.

> BTW when I tested the current stable-tracking which is 2.6.27-rc5+, I
> tried starting a rootfs and jffs2 blew chunks on it.

I think what happens is this:

- the wrong ECC algorithm finds lots of problems, as one would
  suspect
- most of them look like multi-bit errors and are silently ignored
  (JFFS2 has its own CRC and doesn't use the ECC statistics from MTD)
- however, some look like single-bit errors. MTD then tries to
  "correct" them.
- JFFS2 complains about these because the CRC is wrong.
- after that, a swift and merciful death is all you can hope for :-)

> All but one IIRC came out in the device tree re-ordering.

Great ! Let's hope the monsters there stay dead for once ;-)

> That answer came out very smoothly, but I am not sure you quite
> understand what the current set of branches are for.

Hmm, I read what you wrote twice and I see the logic in it.
However, I don't see how this would be better than just doing
the cleanup right away.

Deferring the cleanup until it comes back from upstream only means
that

- bug fixes will have to be cherry-picked between the parallel
  branches,
- there will still be a big merge at the end, with cleanup and
  new development both contributing to the differences,
- developers working not only in their own corner have to keep
  track of both branches,
- and any problems in the cleanup itself will only be found much
  later when they're coming back.

So I don't really see the benefit. It's just more work, more
mistakes, and you'll have to come back and remember tasks months
after they were finished. Also, cleanup is not just art for art's
sake but serves the very real purpose of making the code easier to
understand and to maintain, which would also benefit any new work
on the main branch.

By the way, while I admire your ability to keep all those parallel
branches from becoming one tangled mess, I don't think we have to
be afraid of tracking upstream a lot more closely.

Tracking upstream is hard at the moment, because there are so many
places where we can conflict, and because other developers break
things we depend on because they don't even know our code exists.

Since upstream gets a lot more exposure than Openmoko kernels, any
bugs that aren't our own making will get fixed there more quickly,
and we save the effort of searching for fixes to cherry-pick and
the cost of missing them.

So it's good to update frequently, and to reserve large-scale
branching for those cases where you only fix the truly cataclysmic
failures and document the rest.

- Werner