> From: "Mark Brinicombe" <amb@physig4.ph.kcl.ac.uk>
> Date: Tue, 2 Jul 1996 14:11:32 +0100
> 
> >However, I do think that at some stage the RISCBSD team should consider
> >'freezing' development for a month or so while they catch up on
> >documentation, tidying up the FTP site and CD etc.  This must be almost
> >impossible to do on a 'moving target'.
> 
> >I'd also recommend re-writing the instructions on the assumption that
> >some people are going to use UNIXFS for transferring sets... I had nearly
> >resigned myself to buying a boxfull of floppies before I found UNIXFS!
> 
> Yep I would love to freeze development if only there was not so much I have to
> do ...
> 
> A significant code freeze is upon us though. NetBSD 1.2 is in a code freeze
> position at the moment and I have starting to build test snap shots (I'll put
> some several new 1.2 bits up later today)
> Once 1.2 is release I do not expect very many changes to the the standard
> binaries. A new CD release will be built from the 1.2 release and I do not
> expect many changes to be made to that.
> I have plans to tidy up the ftp site but as with most things time is precious.
> The 1.2 freeze also freezes a 1.2 kernel. This does not mean development has
> stopped. it just means that 1.2 is a frozen development branch which should
> have a lot of the bugs ironed out.
> 
> However a lot has changed in the kernel since the 1.2 branch was cut. major
> bugs fixes will go in but I have done things like rewritten the IRQ subsystem
> (drastically reducing latency). This work is not in the 1.2 kernel.
> 
> As a result I expect to see folks running a 1.2 release with just the kernel
> being updated more frequently.
> 
> Also on the point of documentation....
> 
> The idea is that users also contribute. I could be wrong here but I suspect the
> reason users are not writing device drivers, debugging the kernel etc. is that
> they do not fully understand it and that it is rather complex.=, not to mention
> lack of time.
> Now if I freeze all riscbsd development for a month and write docs then no
> kernel development will happen. If you ask most users I would suspect that they
> would prefer me to spend my time working on the kernel rather than docs as docs
> are something that other people can write but the kernel isn't.
> 
> When you have a number of things to be done it is surely better to make the
> most of the skills those people have.
> 
> Ok enough of the ranting ;-)
> 
> Perhaps we need to organise a group to work on documentation.
> As well as a new install guide we could do with guides other parts of RiscBSD
> e.g. X, networking, building kernels etc.

I think that to organize a group to work on documentation is a good
idea.

Also, I believe that working on the documentation is a good approach
to actually learning what RiscBSD is all about.

Until I know more about the internal workings of RiscBSD, I see three
areas in which I could contribute:
1) Writing documentation
2) Porting new software or recompiling for new versions of RiscBSD
3) Testing RiscBSD

Kjetil B.