Quotes of the week [LWN.net]

Quotes of the week

Posted Oct 14, 2010 5:22 UTC (Thu) by neilbrown (subscriber, #359)
Parent article: Quotes of the week

> Anybody who _designs_ for that kind of disaster shouldn't be participating in kernel development,

Not sure I agree with. Rather people who don't design for it should be questioned.

The reality is that we all make mistakes. So we have 3 options.

1/ Keep new designs out of mainline until they are close enough to perfect.
2/ Support broken designs in mainline indefinitely
3/ Plan for the inevitable and ensure there is a mechanism for removing bad stuff with minimal pain.

1 is discouraged by the 'upstream first' policy that is widely encouraged.
3 is discouraged by Linus, it seems.
That leaves 2, an obvious default, but not a pleasant one.

We do have a rough mechanism for deprecating features, but that is only part of the answer. I would really like to be able to mark a feature so that a developer needs to be consciously aware that it is experimental before using it. And I don't think 'CONFIG_EXPERIMENTAL' really serves that purpose. I'm not sure what a good answer is though.

It should be noted that Linus' comment is taken a little out of context - it is a very broad statement made about a very specific context (which is not atypical for Linus :-) It may be that he is right in that context without being right in general.

to post comments

Quotes of the week

Posted Oct 14, 2010 15:48 UTC (Thu) by bronson (subscriber, #4806) [Link]

or: 4/ Plan for the inevitable and ensure there is a mechanism for adding functionality without removing or breaking anything.

In other words, try to anticipate what people will need in 3 years and make sure you can easily accommodate it. Don't use bitfields (or, if you do, make sure you leave more than a few bits free).

That's my interpretation, seems consistent to me.

Agreed, CONFIG_EXPERIMENTAL doesn't mean much. I'm not sure it can be improved, though, because pretty much any alternative would fall into the same "technical solution to a social problem" trap. We application programmers love new features, we will adopt them as soon as we can, and we will howl if they break. Alas.