On Tue, May 02, 2006 at 02:06:10PM -0500, Eric Lowe wrote: > This brings up an interesting point, which is that we may have a lot of > community supported, but non-Sun-supported, features some day, starting > from this one (and with resurrecting the le driver which is related to > this revival for supporting non-1E Ultras). > > Keeping such code out of the consolidation doesn't seem fair; Linux has
Agree. > the notion of unsupported code too -- it's pretty much "as long as it > compiles it's up to the users to fix it when it breaks" but otherwise no > guarantees are made. That's not acceptable. The gate is a shared resource; once something is putback, we all agree to maintain and support it as a first class citizen for as long as it remains. We are absolutely not going to go down the Linux path of incorporating garbage and letting it rot in the gate forever. The end result of that strategy can easily be seen in the array of variably broken crap in Linux; users of the broken features can never actually use the gate anyway and are invariably forced to use externally maintained patchsets. Once you acknowledge that something in the gate can be broken at will by subsequent putbacks, and that users who want the feature must forever get other patches to make it work, you might as well not bother including these features in the gate at all; just maintain the feature elsewhere, because you'll have to do that anyway. > One could envision an environment variable you set in your nightly.env > file to enable compiling in such code. Sun could compile Solaris without > this switch set, to prevent having "unsupported" code build into their > distribution, while other distros could build with it enabled? It would be much better if this were done on a per-file or better yet per-package basis, so that distributions could, as they do today, elect to include or not include a particular feature. I don't think adding a lot of #ifdef SOLARIS is the right answer here - after all, do we then allow integration of #ifdef SCHILLIX, #ifdef BELENIX, etc.? If the project team can't isolate their feature well enough that it can be easily excluded if desired, and they can't convince other contributors that the feature is worth the cost of supporting it as a first-class citizen, then the project really doesn't belong in the gate. That's not necessarily the case for US-I support - scoped properly, this project could provide worthwhile benefits with little impact on other code. But before anyone asks, sun4m (or any other project proposing to restore the 32-bit SPARC kernel) would be both impossible to isolate and excessively costly for all contributors. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
