On Tue, 2006-05-09 at 09:49 -0500, Rex Dieter wrote: > Jeremy Katz wrote: > > On Tue, 2006-05-09 at 00:11 -0400, Jesse Keating wrote: > >> On Tue, 2006-05-09 at 00:01 -0400, Greg DeKoenigsberg wrote: > >>> 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. > >>> > >> Or do we fire up thoughts on Alternatives again? Somewhere that we can > >> host replacement packages that folks can use to assemble 'Fedora' > >> variants but not be tied to the kernel or whatever. If we use the same > >> rules, or come up with a good rule set for Alternatives, same package > >> quality, same build systems, etc... we should be able to call it Fedora. > > > > How do you define "same package quality" if it's an alternate > > implementation? > > It follows the same packaging standards, review process, etc... But it hasn't followed the same review process as the patches that make it an alternative haven't been through the review process of the upstream community. > > And starting to get bug reports from J. Foo's Fedora > > that has a drastically different kernel or glibc or ... is going to make > > things very very difficult for developers. > > Not for you, for whoever is maintaining the Alternatives pkg. And when the alternative package has a subtle interaction with other packages breaking them? And these things *do* happen... we're starting to see some of them already with Xen and have previously seen them with other packages changing. Jeremy