move to rawhide update

[Daniel Drake]

2009/4/8 John Gilmore <gnu at toad.com>:
> Since OLPC's "upstream" is both Linus's kernel releases, and Fedora's
> distributions, there are two upstream places to push OLPC's hardware
> support patches to.  Have we only been trying to get them into one of
> those places (Linus's)?
>
> The F11 kernel currently carries about 60 patches beyond Linus's version.
> Some are tiny 4kb patches; others are 300KB.  Why aren't any of the
> XO-1 hardware support patches included in the F11 kernel?

I don't think any effort has been made (since layoffs) to get any
kernel patches upstream anywhere, mostly due to time constraints. But
anyone is welcome to step up and do so!

During a quick discussion with Chris and some others we seemed to
agree on the following:
 - regardless of Fedora/F11/F12 status, policies or whatever, the
first thing to do in any case is to get the patches upstream to Linus
 - we haven't actually tried sending our patches specifically to
Fedora (knowing that they aren't quite ready for Linus) - but IMO this
would be a bad idea
 - we don't really know Fedora's kernel policies for accepting
non-upstream patches, or for backporting upstreamed patches into
current Fedora kernels
 - my opinion: getting patches upstream to Linus, or perhaps even as
far as linux-next, would be enough for the fedora kernel maintainers
to include the patches in the F11 release kernel as an update. So
let's not rule out suspend-on-F11.. it's possible that
F11-plus-updates may work in future.

The biggest showstopper right now seems to be finding someone to do
the work of upstreaming the patches. And, in my opinion and
experience, the correct way to do this is to approach upstream saying

"hey, we have this weird hardware, how would you like to see the
kernel code crafted? here's a possible patch to act as the basis of
discussions"

and *not*

"hey, we have this weird hardware, please take our patches as-is
without consideration because we've shipped them internally for 2
years"

which makes the task harder (since kernel hacking may be needed as a
result of discussions), but should lead to success :)

Daniel