On Wed, 2006-05-10 at 10:56 -0400, Christopher Blizzard wrote: > Tim Burke wrote: > > Just to share some exposure into what it takes to keep a non-standard > > kernel working in the Fedora tree: > > - Pretty much a full-time dedicated highly experienced kernel developer > > to spend the vast majority of their time playing patch monkey to keep up > > with the high rate of upstream change. We have someone doing this role > > for Xen and its more than a fulltime job. Same thing would have to > > happen for an OLPC kernel. Certainly the amount of work is commensurate > > with the nature of the changes. Having seen the RT patch set, that is > > invasive and would also require similar effort. > > I've got Marcelo Tosatti and David Woodhouse to do this work for OLPC. > I'm hoping that they will be able to do most of their work upstream and > we pick up changes that way but I know that we're going to have local > changes both for the same of experimentation and because maybe we need > something that hasn't been taken. In either case, we're going to have > to have a variant for OLPC. I'm sure that RHEL doesn't care about the > things that we do and we don't care about 90% of the RHEL drivers. :) 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. > > - As was pointed out earlier, the path to the Fedora kernel leads from > > upstream. > > It is but the idea that "one kernel is enough" doesn't fly when you're > supporting more than one product, certainly from the RHAT side of the > fence and even more so when we're trying to enable other people to use > Fedora to experiment and do other interesting things. We need to get > creative and find a way to scale instead of just saying "it's hard." Ok, I'm going to stumble here a bit because I think we're coming at this from two totally different viewpoints. Bear with me. What products is Fedora supposed to be supporting? If you look at it from existing kernels today, I see: stock, Xen, GFS, cman, dlm and gnbd. Then we're talking about others like OLPC, CCRMA, etc. Now, take a step back and look at all that for a second. How many of those are really installed by the typical Fedora user? I'd say probably 2, stock and Xen. Why? Because those two have the most value to the majority of Fedora users. (Yes, I'm completely ignoring the fact that the other kernels have a large value to Red Hat as a _company_. Hopefully you'll see why in a second.) 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. So, how can we enable those that want to play with these other kernels? I think it's going to come down to something along the lines of having those kernels be projects in and of themselves. And by project, I mean projects like plague, mock, etc. That's part of the reason I'm so interested in getting a hosting system in place that works and works well. It would allow those that want to tinker with things to either build the kernel themselves, or pull from a project specific repo. Now, once those kernel projects become more stable, then you can take a two pronged approach. You start pushing stuff upstream, and you start moving stuff into Core as Xen, GFS, etc are currently done. But trying to actually do _development_ of the kernels that way just doesn't scale and causes the burnout that lots of people have talked about already. So here are the questions that I see: 1) Who maintains kernel project X? Depends on the project. For something like OLPC, it would be David and Marcelo obviously. And if a project fizzles and dies, then it probably wasn't going to have tons of value add anyway. 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. 3) What about the "bugs reported against the Fedora kernel incorrectly" issue? I'm naively hoping the ideas for the bug reporting tool that Will and Greg and others are kicking around will help with that :). I have no good answer for this, mostly because when you talk about multiple kernels there really is no golden bullet for this problem. Is this all a crack-rock idea? Maybe. I got little sleep last night and probably shouldn't be thinking too hard about anything important. But I do think Chris is right. One kernel isn't going to cut it for all the "products" that are being played with and even all the users out there. At least with kernel projects the opportunity for external people to dig in and help out becomes a bit easier to achieve. josh (And yes, having a bitbucket kernel project would be possible I suppose. But I don't think it's sustainable in the long run and I don't think you'll find anyone willing to maintain it.)
