Alexander Vysokovskih | 12 Jun 2008 22:33

Overdocumentation

Hi All!

    What do you think about starting an overdocumentation project for 
kernel source code?
Idea of overdocs is represented  <at>   http://www.os-forum.com/minix/net/ 
(Minix Overdocumentation Project).
Surely, I understand - it's almost impracticable plan, but 
wiki-principle can help.

---
Alexander Vysokovskih

Hubert Feyrer | 13 Jun 2008 10:20
Picon
Favicon

Re: Overdocumentation

On Fri, 13 Jun 2008, Alexander Vysokovskih wrote:
>   What do you think about starting an overdocumentation project for kernel 
> source code?
> Idea of overdocs is represented  <at>   http://www.os-forum.com/minix/net/ (Minix 
> Overdocumentation Project).
> Surely, I understand - it's almost impracticable plan, but wiki-principle can 
> help.

Impressive project... FWIW, there's a start at this in the NetBSD 
Internals Guide: http://www.netbsd.org/docs/internals/en/

Patches are always welcome! :)

  - Hubert

Jeremy C. Reed | 13 Jun 2008 17:55

Re: Importing docs back into usr/share/docs

On Mon, 17 Dec 2007, Tim Rightnour wrote:

> I would like to start importing back in some of the old documentation 
> from 4.4BSD (working in conjunction with Matt Fleming).  However, rather 
> than import things as 02.foo, I would like to import it as just "foo".  
> This way, if we decide in the future to update some of this 
> documentation, we are not bound by the chapter numbering of the past.
> 
> While we could allways do that anyhow, the problem is that it becomes 
> confusing to have chapter 7 be 02.foo.
> 
> I don't see a need however, to delete and move the stuff we have to 
> different names, just newly added stuff.  Moving it about inside the 
> repository would just be churn.
> 
> (yes, I already jumped the gun on smm/config, which I can back out if 
> need be)

Sorry for the very late reply!

Yes, please import what you have. And yes feel free to import without 
chapter numbering as part of file name. Either way doesn't matter to me.

Thanks for your work on this.

Alexander Vysokovskih | 13 Jun 2008 21:28

Re: Overdocumentation

Hubert Feyrer wrote:
> On Fri, 13 Jun 2008, Alexander Vysokovskih wrote:
>>   What do you think about starting an overdocumentation project for 
>> kernel source code?
>> Idea of overdocs is represented  <at>   http://www.os-forum.com/minix/net/ 
>> (Minix Overdocumentation Project).
>> Surely, I understand - it's almost impracticable plan, but 
>> wiki-principle can help.
>
> Impressive project... FWIW, there's a start at this in the NetBSD 
> Internals Guide: http://www.netbsd.org/docs/internals/en/
>
> Patches are always welcome! :)
>
>
>  - Hubert
I suppose, Internals Guide must display architecture of NetBSD, no needs 
to deeply climb in technical moments for it?

Hubert Feyrer | 13 Jun 2008 21:38
Picon
Favicon

Re: Overdocumentation

On Sat, 14 Jun 2008, Alexander Vysokovskih wrote:
> I suppose, Internals Guide must display architecture of NetBSD, no needs to 
> deeply climb in technical moments for it?

wlel, what do YOU have in mind?

  - Hubert

Alexander Vysokovskih | 29 Jun 2008 15:17

Re: Overdocumentation

Hubert Feyrer:
> wlel, what do YOU have in mind?
>
>
>  - Hubert
>
Sorry for a long answer delay.  IMHO, to stay netbsd developer need to 
spend more time and efforts, them for linux, because of insufficiency of 
the developers documentation. As I know many of "young" developers (I'am 
to;) sympathize *bsd systems, especially netbsd. But hard to start, really).

What do you think about doxygening+graphvizing source codes for beging?

With regards,
    Alexander Vysokovskih

Hubert Feyrer | 30 Jun 2008 12:22
Picon
Favicon

Re: Overdocumentation

On Sun, 29 Jun 2008, Alexander Vysokovskih wrote:
>> wlel, what do YOU have in mind?
> What do you think about doxygening+graphvizing source codes for beging?

That sounds like an interesting project, and indeed there seems to be a 
similar project for Linux that does that (name forgotten, it was on /. the 
other day).

Maybe set it up, and if comment updates are needed for doxygen, that 
should/can be discussed?

  - Hubert


Gmane