> It is also important to distinguish what's best
> for *you* and what's best for the project.
> Maybe *you* don't want to be responsible for
> doing all the documentation.
>
> I'm not even going to attempt to document something that
> moves as fast as the kernel.
That point is a real problem...
> I go to bookstores and I see many excellent attempts to document
> kernel internals, but these books are frozen in time. Specifically they are
> frozen in the time of the moment the kernel they write for is published. As
> a consequence they are all obsolete the moment they are published.
No doubt.
> Some poor student reads these books, written against 2.4.8 or
> whatever, then they go and try to contribute to 2.5.x and it
> doesn't work except for certain kinds of drivers where we've
> kept the APIs more or less the same.
>
> But I don't care that people do this, just don't require that I do it.
Sure. Are you willing to answer questions about it at least?
> I think this extra fluidity we get from being able to change so fast is a
> strength not a weakness.
If it were only a strength, that would be great.
I believe that it's both, however.
~Randy
|