On Tue, 2006-05-09 at 09:47 -0500, Rex Dieter wrote: > Jeremy Katz wrote: > > On Tue, 2006-05-09 at 00:01 -0400, Greg DeKoenigsberg wrote: > >> On Mon, 8 May 2006, Stephen John Smoogen wrote: > >>> I think that this request may fit into more of an Alternatives project > >>> where multiple kernels and other tools might be able to look at. > >> Yeah. We killed off Alternatives a while back -- not because it wasn't a > >> good idea, but because it wasn't a good idea at the time. > > > > I'm still not convinced it's a good idea... it does little to encourage > > actually getting things merged. And lots of forks ==> more work. > > Yeah, but it's not *your* work, it's someone else who *wants* to do it. > I think we should foster an empowering environment, and not take a > stance of "you can't do that!". Except that bugs inevitably get misfiled or misattributed and so it is a significant chunk of work. > >> Here's the fallback position: Fernando continues to maintain the CCRMA > >> kernel in his own yum repo, and *everything else* gets pulled into Extras > >> over time. (To the best of my knowledge, none of the CCRMA apps *require* > >> the CCRMA kernel -- it's just a huge help for getting any actual work > >> done.) That way, at least Fernando has a mechanism to spread the workload > >> for maintaining CCRMA among several assistants, and can spend most of his > >> time maintaining his own kernel as he sees fit. > > > > While that can work, I think this puts users in the worst place as a > > non-mainline kernel will inevitably lag in terms of security fixes, etc. > > And any kernel modules that are built in Extras won't be able to be used > > for that kernel. > > Well, that should be their (the users') call to make, understanding the > risks/rewards for using bits from Alternatives (of CCRMA). Explaining that clearly is not going to be easy, if it's even possible. Jeremy
