Do you mean a "cvs" type tool?
>: The documentation could probably be laid out in a format similar to
>[stuff deleted]
>
>What about requiring some type of formal requirements and design
>documents for each kernal subsystem/device driver? These wouldn't
>necessarily need to be pretty, structured documents, but they
>would need to have certain specific information that could convey
>information about a subsystem to the level of understanding
>necessary to fix minor bugs and otherwise maintain the code.
Good, as long as someone other than the coder takes the responsibility
of maintaining said document. I don't think it's to anyone's benefit to
delay code changes so that docs can be written.
In fact, sometimes it might be good to hold off a few days before
writing the detailed parts of the documentation, to let the code start
to "finalize". Although something major like "skbuffs" or "dentries"
rarely seems to be "backed down from", and the actual "forgot to i++"
type patches don't really affect documentation.
>: I would be willing to maintain the files, although I don't have enough
>: knowledge yet to actually write most if any of them.
>
>I would also be willing to help coordinate any efforts and possibly
>create doument templates or such to help get people started.
I have web space, and would be willing to do that end of it.
>Agreeed. Documentation discussions should be moved to a separte list
>as soon as possible.
>
>
>Randy Scott <scottr@wwa.com>
>
Anyone who can host a mailing list? Can a list be added to vger?
--kmb203@psu.edu----------------Debian/GNU--1.3---Linux--2.0.30---
You have new mail in /dev/null