lkml.org 
[lkml]   [1997]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: kernel documentation is bad
Date
And lo, Michael L. Galbraith saith unto me:
> > > If we forced documentation rules, this would kill kernel developement like
> > > nothing else. If you worry about docs, you arent going to bother molding
> > > and shifting the code.
> > Forced documentation rules are one thing. Not documenting a major
[snip]
> I don't like that 'F' word.. you both used it as if it were an option.
I don't like it either, and know better than to think it's a real option.

> If this thread manages to resolve the PM issues (valid), it'll be in every
> PM text in every university in world.
PM? Patch Management? Provocative Maintenance? Post Meridean?

> I'd rather be trying to figure out the next cool patch.
I'd rather, when trying to figure out the next cool patch, not having to
sweat how to hook it into Linux and figure out by brute force what the
undocumented code isn't telling me that nonetheless breaks my cool patch.
That is the point of good documentation of the internals: giving the
generally competent masses the power to fix and add things correctly,
without having to resort to blood sacrifice to be able to understand
what they're fixing or interfacing with.

And if you do come up with a "cool" patch but can't be bothered to document
it yourself, why should the developers and maintainers waste their time
figuring out what you're doing and why before evaluating its correctness
and suitability for inclusion in the main distribution (or why should they
trust you to know what you're doing when you can't be bothered to write
code that shows it), when they could be working on "cool" patches
themselves?

Keith

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.142 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site