On Mon, Feb 25, 2013 at 12:39:27PM +0000, Stefano Stabellini wrote: > On Sun, 24 Feb 2013, Greg Kroah-Hartman wrote: > > > > You should not have unstable options in the kernel in the first place, > > sorry. > > With the premise that the removal of CONFIG_EXPERIMENTAL is not an issue > for me personally or my work, I am going to give you my 2 cents on the > matter, but feel free to ignore them :) > > While I understand that CONFIG_EXPERIMENTAL has been abused, I feel that > rejecting everything that is not fully stable and with external > interfaces set in stones, might hinder the development of new features. It's been this way for _years_ this isn't something new (the "you have to get it right really quickly" problem). See Documentation/ABI/ for some words about how you can try to do this. > After all, given how fast the kernel is moving nowadays, No faster than it has in the past. > maintaining a project out-of-tree until is completely ready for > production can be very expensive. Merging the project earlier and > completing the development upstream can bring better results. Yes, but don't go changing user-visable apis when you do so. That's been a hard rule for a LONG time. > But in these cases one wouldn't want to "market" the feature as stable > yet, because it just isn't. If CONFIG_EXPERIMENTAL is going away, is > there anything in the kernel that can be used to tag a feature as "I > wouldn't use it in production if I were you"? Maybe just a comment in > the kconfig description? I know this is hard, I've had my own problems with it in the past. You don't know if you get an api right until you have a lot of users. See our previous "discussions" about this topic on lkml if you are curious as to the eventual outcome of threads like this: Yes, it's hard, but that's kernel programming. Sorry, greg k-h _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
