Christopher Blizzard (blizzard@xxxxxxxxxx) said: > I need to worry about the fact that I need a kernel that has wildly > different preferences and possibly patches than the stock fedora kernel. > We will not be using the stock i686/i586 kernel. We know we do most > of that work upstream, but what about the stuff that doesn't? And the > fact that it has a different config? A separate config on top of common upstream code is relatively simple; it may break building, but it is generally easy to fix. Keeping separate codebases working on top of upstream *cough*Xen*cough* is another matter entirely. The question is how to make this easier for people - tinderboxing? Alerts of breakage on new checkins *to upstream*? What sort of tools can we make that make this easier, whether it's for the Xen maintainers, the CCRMA people looking at real-time patches, or even for someone who just wants to add a new-not-yet-upstream wireless driver? > This is the one that I think we're going to have the most problems with. > Even in the "play" case above, people still want reasonable security > updates. And the farther that you fork from the main kernel the harder > it is to come back and apply security updates. > > I'm not sure what to do about this case, but we need some creative > thinking. We want people to be able to follow, modify and keep updates. > From our tree (think productize, as OLPC does) our outside of our tree > (think audio projects/realtime patches.) How do we enable that and > create the best incentives to keep updated as closely as possible? The 'as currently done' approach would be: - keep your own maintainer. Charge him with fixing it for each security update This is not the most scalable solution, obviously. Perhaps this is the carrot/stick that encourages people to get their code upstream; I'm not sure. Bill