Bill Nottingham wrote:
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*?
As an example, OLPC is both of these things. In the end it's probably a
separate config, but between now and when we ship we're going to need to
do patches + stock kernel for testing and integration. This is really a
product lifecycle issue for me and right now our current process are
really only around one lifecycle: the Fedora and RHEL lifecycle.
THe question that I see is: how do we allow people to experiment in some
kind of blessed way that enables them to do so, and still allows our own
processes to move forward and scale?
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?
Not sure. We're probably shy about writing tools, but I think we need a
stronger problem definition and research before we even start talking
about ideas around tools. I feel like we're getting some sense of the
problem statement, though.
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.
It's most certainly a stick! :)
I think that "keep your own maintainer" isn't enough. I wonder how we
can move to "act as a co-maintainer." i.e. let's give Dave Jones a
break and still enable us to scale this out a bit.
--Chris
