Josh Boyer wrote:
Working upstream and in a fashion that is acceptable to upstream are two things that David and Marcelo are exceptionally good at. I don't think you need to worry about that particularly.
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?
You bring up an excellent point in that there _are_ people that want to do new and interesting things with Fedora. And that if those people _are_ interested in some of the other variants, they should be accessible. However, I don't think having all of those kernels being officially pushed out by the buildsys is required. In fact, it often doesn't happen anyway because the patches don't apply or build at any given moment.
I think you're right. So I will create a dichotomy here. I think that the two things we're talking about here are 1. people who want to experiment and play and 2. people who want to drive something to product status. Both of them are valid and both of them need to have Fedora as the center point for the code and the effort.
2) What about all the security issues? My cynical approach on that is they happen anyway, even with today's model so it's not really different. Think about it. A user has xen kernel X installed from rawhide. A new kernel is pushed out that fixes a security issue, but Xen doesn't build so it doesn't get a kernel update. Does that user reboot into the new kernel even though Xen doesn't work? That choice is largely up to them and it still would be with doing stuff in a project. It's not ideal, but I don't think it's any worse off.
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?
--Chris
