Messages in this thread | | | From | Keith Rohrer <> | Subject | Re: kernel documentation is bad | Date | Mon, 21 Jul 1997 18:55:55 -0500 (CDT) |
| |
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
| |