[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DNS volunteer needed
- Subject: Re: DNS volunteer needed
- From: Vladimir Vuksan <>
- Date: Sun, 24 Oct 1999 20:45:07 -0600 (MDT)
- Resent-Cc: recipient list not shown: ;
- Resent-Date: 25 Oct 1999 02:45:16 -0000
- Resent-Message-ID: <DcgKEB.A.AXE.8Q8E4@murphy>
On Mon, 25 Oct 1999 firstname.lastname@example.org wrote:
> OSWG are making very interesting inroads.
> They seem to have decided on some document standards, have just about
> completed a CVS server, building a HOWTO repository and are discussing
> licensing issues. They even managed to produce a nice logo without
> prizes, in a couple of weeks and with no banner ads.
This was a message posted by Daniel Barlow in regard to the new OSWG CVS
repository for all who are interested.
>From email@example.com Sun Oct 24 20:43:39 1999
Date: 24 Oct 1999 20:34:24 +0100
From: Daniel Barlow <firstname.lastname@example.org>
To: OSWG Mailing list <email@example.com>
Subject: [oswg] CVS repository now available
The structure is heavily influenced by what the FreeBSD people have
done, so start by reading Nik Clayton's previous post to this list at
There are a few differences and/or points that that doesn't cover:
1) We treat English no differently from any other language (contrast
the FDP archive, in which the 'original' English man pages are off
in /usr/man, and only the translations are here)
2) We can't make the packaging system work for us as seamlessly as
they can, because we have to cater for multiple systems and
distributions. (This is not just Red Hat Linux ...)
There is a top-level directory /oswg/bin in which people are invited to
place scripts that will do the appropriate thing on their system to
turn SGML into HTML or PS or ..., to install manual pages, to
produce an RPM, whatever.
3) There is no big top-level Makefile. I don't even know if people
will want to check out the whole repository if they're only working
on one document, so it may not be appropriate. Discuss.
4) The 'important' file - the main file for the "source form" of the
document - is the one with the same name as the directory, plus
appropriate extension. For example, there is the directory
When there's a document actually there, it will be
In the meantime, the directory can be (is) used as a dumping ground
for other files, bits of source material, graphics, subsidary
files, etc. We know they're not release candidates because they
don't have that name. That means that contributors who aren't
doing their own DocBook markup can put their plain text (or
whatever) into CVS as a way for the marker-uppers to get hold of it
The other important file for each project is probably a README that
says whose project it is, how they can be contacted, what needs
doing, how and whether they'd prefer you send changes, etc.
5) Issue not addressed: how to deal with hyperlinks between documents.
At this point I just want to let people start getting the source
text in, and have someone else worry about how to hyperlink between
documents when there are some documents to link between.
6) There are also man page directories in there, though probably not a
full set. I'm going to suggest that each man page doesn't need its
own source directory, but can be the single file "foo.1" (nroff
source) or the pair of files "foo.1" (nroff source) and "foo.txt"
(text document that someone else is expected to convert into nroff
For an account, mail firstname.lastname@example.org with preferred username and
crypted password (see my mail of earlier today)
Once you have an account, you do something like
$ CVSROOT=:pserver:email@example.com:/home/cvs/cvsroot; export CVSROOT
$ cvs login
;; supply your password at the prompt
$ cvs checkout oswg
;; wait a while
If you use a C-like shell (csh, tcsh) rather than a Bourne-like (ash,
bash, sh, zsh) that first line won't work - instead use the equivalent
$ setenv CVSROOT :pserver:firstname.lastname@example.org:/home/cvs/cvsroot
Once you've logged in once you won't need to again unless you lose
Enjoy. Start, if you like, by looking at the aforementioned
linux-c-programming guide and figure out if you want to write any
portion of it.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org