v04INF1: Introduction to comp.sources.reviewed
David Boyd
Posting-number: Volume 4, Info 1
Archive-name: intro4
Supersedes: intro3: Volume 3, INF 1
Last-modified: 12-Oct-1994
This is the first of five introductory messages about the newsgroup
comp.sources.reviewed. It describes the newsgroup's history, how to submit
sources to c.s.reviewed, where the archive sites are, and how to contact
and access them. The second and third postings are the guides for submitters
and reviewers respectively.The fourth posting is the index of previously
posted software. The fifth article is a cross-index of patches that have been
posted to this newsgroup.
As always, I am looking for suggestions on how to improve the usefulness
of the newsgroup. *Please* do not hesitate to send suggestions to
comp.sourc...@ftp.sterling.com.
Dave
--------------------
0. Contents
This file covers the following topic areas. If you are interested in
reading a specific topic you can go directly to it by '^number-of-area'
('g^number-of-area' if you are using trn).
1. Introduction
2. Deciding where to post your software
3. The structure of comp.sources.reviewed articles
4. Guidelines for submitting source for publication
5. Patches Handling
6. Special services
7. Reporting and tracking bugs.
8. Newsgroup Status Information.
9. Accessing the archives
10. Archive access via ftp
11. Archive access via uucp
12. Archive access via email
13. Extracting a retrieved archive member
14. Becoming an archive site
15. Listing of archive sites in no particular order
16. How to become a reviewer
17. Credits
--------------------
1. Introduction
"Comp.sources.reviewed" is a moderated newsgroup (moderator: David
Boyd [comp-sourc...@sterling.com]) with the following guidelines:
Comp.sources.reviewed is a moderated newsgroup for the distribution of
program sources that have been subjected to a Peer Review process.
Similar to the process used for academic journals, submissions are sent
to a moderator who then sends the sources to Peer Review volunteers for
evaluation. The Reviewers are asked to provided a timely evaluation of
the software by compiling and running it on their machine. If time does
not permit them to complete a review, they are responsible for asking
the moderator to select another reviewer. The completed reviews will
be collected by the moderator and provided to the author of the software
along with a recommendation as to whether the software should be posted
in its current form. The author can then decide whether to post the
software, make the recommended corrections and re-submit the software
for another round of reviews, or withdraw the software from the review
process. In cases of dysfunctional software the moderator reserves
the right to override the Author's decision and reject the package for
posting. Upon agreement between the Author and moderator to post
the software, the sources will be posted along with the written comments
provided by the Reviewers. In all cases the Reviewers' comments will
be posted as well.
--------------------
2. Deciding where to post your software
There are four choices for sources newsgroups, not counting regional
sources groups (fl.sources) or groups for specific systems, such as
comp.sys.sun.*, comp.sys.mac.*, etc. Choosing between them can be
somewhat difficult for the novice, and even for seasoned sources posters
with unusual submissions. Here, then, is a discussion of the various
"primary" sources groups, their advantages and disadvantages, and a very
crude attempt at quantifying when to use them.
First off is comp.sources.unix. It is unfortunately named, but don't
let that stop you from trying to submit something if it fits the group's
guidelines otherwise. The benefits you'll get are testing of source on
at least some machines before posting and guaranteed archiving at many
Internet and UUCP sites. The problem is that smaller postings aren't
usually accepted, as well as submissions that don't have a Makefile, a
manual page and a README file. Also note that the current policy of
comp.sources.unix is not to accept "shareware" programs, programs which
request or require a fee to the author for continued use.
Second is group, comp.sources.misc. The original charter
called for moderation solely to reject non-source postings, nothing
more; the intent was to provide net.sources without the noise. This
grew as a policy was adopted of letting the group be controlled more by
its users (submitters, readers, archivers) than by "moderative fiat".
The advantages of posting here are that archiving is as widespread as
comp.sources.unix, anything which is source code can be posted, and it's
guaranteed not to be lost in non-source, discussion postings; the
disadvantages are that there is a slight delay caused by having to
filter stuff through the moderator.
For small sources and beta copies of programs (which probably should not
be archived, in favor of a future production release), one might choose
alt.sources. It has one major advantage over the other possibilities:
there is no moderation, meaning no delays and no rules for formatting.
(It is suggested that you add an "Archive-name:" to your postings so as
to help out those who do archive the group.) You're free to just pipe a
source file to inews if the fit takes you (not that I recommend it). It
also has one major disadvantage: since the group isn't moderated, there
is nothing preventing people from starting up discussions ranging from
source code topics to why EUnet works the way it does. This, if you'll
recall, is what caused comp.sources.misc to be created in the first
place. Another disadvantage is that, being an "alt" group, it doesn't
get as wide a distribution as the "mainstream" Usenet. (For further
information on the "alt" hierarchy, see the "Alternative Newsgroup
Hierarchies" document posted each month by Gene Spafford in news.lists.)
For more information on posting to alt.sources see the "Welcome to
alt.sources!" document posted biweekly by Jonathan Kamens in
alt.sources.
Finally there is this group comp.sources.reviewed. It uses a Peer Review
process to accept or reject submissions. Similar to the process used
for academic journals, submissions are sent to a moderator who then sends
the sources to Peer Review volunteers for evaluation. The Reviewers try
to provide a timely evaluation of the software by compiling and running it
on their machine(s). If the Moderator and Peer Reviewers judge a submission
to be acceptable, the sources are posted along with the comments provided by
the Reviewers. If a submission is not found to be acceptable, the
author is provided with the Reviewers' comments, and the author has the
option of addressing those comments and re-submitting the sources again.
The benefits of this group are that your software will be thoroughly
tested by multiple reviewers on multiple systems prior to it being
posted to the world. A formal discussion of this process from both
the submitters and reviewers point of view can be found in the next
two informational postings.
So which do you choose? While there are no hard rules, there does seem
to be an evolving rationale for the use of the groups: if you wish your
software to be reviewed before handing it over to the world at large then
comp.sources.reviewed is your choice. Since, this group welcomes any and
all kinds of sources then the sole rational for posting to this group
is that you desire the software to be reviewed. If you don't desire
a review then the following rationals should be followed.
If your software is currently unstable, still changing rapidily, or not
quite ready for the formal review of this group then post to alt.sources.
After the software has stabilized or is ready for review then post to
this group or to one of the others for archiving.
In general, games usually are sent to comp.sources.games regardless of
their size. Postscript sources are sent to comp.sources.postscript.
Programs which are specific to a particular computer would be better
off in an specialized sources group like comp.sources.sun or maybe
comp.sources.amiga, and X-Window based applications should be posted in
comp.sources.x. Major programs usually go to comp.sources.unix, and
comp.sources.misc is used for the rest.
Moderators of different sources groups, mainly c.s.misc, c.s.reviewed
and c.s.unix, have been receiving submissions from authors that were
previously posted in another sources group. For the most part the
moderators would like to discourage the kind of group jumping that has
occurred in the past. It makes it harder for the community to point
people to the most current versions if a package appears in more than
one newsgroup. It would be better if authors posted their packages to
a single group and sent future updates to the same group. That way
there never is a question as to which group has the most current
version of the package. This does not mean that we won't accept it.
Just be ready for a question or two so that the moderators understand
that you truly want it that way.
Remember though, it's up to *you* to decide which newsgroup your
submission should be posted to.
--------------------
3. The structure of comp.sources.reviewed articles
Each posting in c.s.reviewed is called an "issue". There are generally 100
to 125 issues in a volume. The division is arbitrary, and has varied
greatly in the past. There are two types of articles in c.s.reviewed;
"source postings" and "informational postings." They can be
distinguished by the subject line.
Subject: v03INF1: Introduction to comp.sources.reviewed
This first word in the title identifies this as the first informational
posting of volume three. Similarly, the subject line shown below:
Subject: v031i072: lc - Categorize and List Files In Columns, Part01/02
identifies this as the 72nd source article in Volume 31. In the above
example, the Part01/02 indicates that this is the first part of a two
part posting. The first few lines of an article after the USENET
required headers are the auxiliary headers
that look like this:
Submitted-by: ke...@sparky.sterling.com (Kent Landfield)
Posting-number: Volume 31, Issue 72
Archive-name: lc/part01
The "Submitted-by" line in each issue is the author of the program. IF
YOU HAVE COMMENTS ABOUT AN ISSUE PUBLISHED IN COMP.SOURCES.REVIEWED, THIS IS
THE PERSON TO CONTACT. When possible, this address is in domain form,
otherwise it is a UUCP bang path relative to some major site such as
"uunet."
The second line repeats the volume/issue information for the aide of
NOTES sites and automatic archiving programs such as rkive.
The Archive-name is the "official" name of this source in the archive.
All source postings are treated as multi-part postings have been done in
earlier volumes. All source postings are stored in a subdirectory within
the volume directory. This gives me a place to store patches. It also
allows me to have more informative archive names without having to worry
about how many spaces the part numbering, patch indicator or compression
suffix require. Postings have names that look like this:
Review posting
Archive-name: lc/part0
Source posting
Archive-name: lc/part01
Patch posting
Archive-name: lc/patch01
Note that the part number and patch number are zero padded. Part 0 is always
the collection of reviews submitted for the package. Also, note
that the "part number" given in the title is used to give the reader an
indication of the total number of parts which make up the complete set
of sources. The example below shows that this is part 2 of a 4 part
submission.
Subject: v32i001: perlref - Perl Reference Guide 4.035.1, Part02/04
Informational (INF) postings, such as the posting you are currently
reading, are not stored in a subdirectory as are source postings. INF
postings have archive names such as indx33v01-07 and patchlog33. From
an archiving perspective, archive names for all INFormational postings
are specified so as to store the INF postings directly in the volume's
base directory. Archive names for source postings are specified so as
to store the sources in subdirectories within the volume's base
directory.
To support the tracking of patches, the Patch-To: line is used. The
Patch-To: line exists for articles that are patches to previously posted
software. The Patch-To: line only appears in articles that are posted,
"Official", patches. The initial postings do not contain the Patch-To:
auxiliary header line.
Patch-To: syntax
Patch-To: package-name: Volume X, Issue x[-y,z]
Patch-To: examples. These are examples and do not reflect the accurate
volume/issue numbering for rkive.
In the first example, the article that contains the following line
is a patch to a single part posting.
Patch-To: rkive: Volume 17, Issue 17
This example shows that the 17-22 indicates the patch applies to a
multi-part posting. The '-' is used to mean "article A through article
B, inclusive..
Patch-To: rkive: Volume 17, Issue 17-22
If a patch applies to multiple part postings that are not consecutive,
the ',' is used to separate the part issue numbers. It is possible to
mix both ',' and '-' on a single Patch-To: line.
Patch-To: rkive: Volume 17, Issue 17,19,20,21,22
or
Patch-To: rkive: Volume 17, Issue 17,19-22
There is only one Patch-To: line found in an article.
If a new release is posted instead of a large set of patches, the new
posting contains a Supersedes: header line with a format similar to the
Patch-To: header.
Supersedes: syntax
Supersedes: package-name: Volume X, Issue x[-y,z]
Supersedes: example
Supersedes: rkive: Volume 17, Issue 17-22
The Supersedes: line is helpful for cleaning archives by providing a
pointer to previous versions that the archive administrators can then
remove from their archives.
The Environment: auxiliary header line is included to give you a quick
indication which resources are required to use a particular issue.
In a newsgroup not restricted to one type of operating system, one type
of machine or one type of architecture there is a need for this type of
information in the header. The intent is to provide you more external
information about the package contained within the posting. This allows
you to determine if the package has special requirements that might
prevent you from using it. It is extremely irritating to take the time
to unpack something just to find out that you can't use it.
The news Keyword: line has been used to a certain extent for this, but
if news articles are saved with 'w' rather than 's' from "rn" or "trn
then the news headers don't get saved with the article.
Environment: syntax
Environment: Keyword [, keyword ..]
Environment: example
Environment: SunView, XView, X11R5, termcap
The keywords usage is case insensitive. There is also a NOT indicator
(e.g. !AIX) so that the moderator can specify that the package runs
on everything "but" the specified keyword.
The following is a list of keywords used within articles that have been
posted to c.s.reviewed and their meanings. Keywords are added to this list
on a first-use basis.
Operating Systems:
AIX - should operate on any AIX
AIX3.1 - should operate on AIX Version 3.1
AMIGA - should operate on AMIGA OS
ATARI - should operate on an Atari ST
BSD - should operate on any BSD based unix
CPM-68K - should operate on CPM based 68000
COHERENT - should operate on Mark Williams Coherent OS
DOS - should operate on DOS
ISC-UNIX - should operate on ISC UNIX
ISC - should operate on ISC UNIX
HP-UX - should operate on HP's UNIX
MS-DOS - should operate on MSDOS
OS/2 - should operate on IBM's OS/2
OSF/1 - should operate on OSF/1
POSIX - should operate any POSIZ compliant OS
SCO - should operate on SCO UNIX
SCOXENIX - should operate on SCO XENIX
SUNOS - should operate on SUNOS
SYSV - should operate on System 5
SYSV/386 - should operate on a 386 running System 5
SYSVR2 - should operate on System 5.2
SYSVR3 - should operate on System 5.3
SYSVR4 - should operate on System 5.4
VMS - should operate on VMS
UNIX - should operate on any unix system... (right...)
ULTRIX - should operate on Ultrix
XENIX - should operate on XENIX OSs
Language Support: (C is the default so normally not specified)
ANSI-C - Requires ANSI compatible C compiler
AWK - pattern scanning and processing language
C++ - Requires C++ Programming language
Flex - fast lexical analyzer generator
Fortran - Written in Fortran
Icon - Written in the Icon Programming Language
INET - Requires BSD networking support
LaTex - Requires the LaTex support
MIPS - Mips C compiler
MSC - Microsoft C
Pascal - Requires a pascal compiler
Perl - Practical Extraction and Report Language
Pro*C - Requires Oracle Pro*C compiler
Postscript- Requires a postscript printer/viewer
TurboC - Requires Turbo C
VaxC - Requires VMS VAX C compiler
Windowing Support:
Curses - Requires the curses library
Sunview - Requires the Xview library
Xlib - Requires the X Windows library
Xview - Requires the Xview library
X11 - Should work on any X Window System
X11R4 - Requires the X Window System Release 4
X11R5 - Requires the X Window System Release 5
System Support: System Utilities needed
Cnews - USENET network news
Csh - The C-Shell command interpreter
C-shell - The C-Shell command interpreter (oops)
DBX - BSD based source-level debugger
DNS - Domain Name System
Emacs - GNU Emacs
getopt - parse command options in shell scripts
HDB - HDB compatible UUCP system. (BNU)
lpr - BSD Line Printer Spooler
MMDF - MMDF mail transport
Oracle - Oracle Database
pathalias - mail routing tool
PBM - Portable BitMap Package
RCS - Revision Control System
Sendmail - BSD based mail transport
Smail - Smail3 mail transport
Sybase - Sybase Database
tput - Initialize a terminal or query the terminfo database
xv - XV image display package
Functionality Support: System supported functionality
sxt - Requires SYSV sxt facilities
symlink - System supports symbolic links
INET - Requires BSD based networking facilities
Hardware Tested on:
Alliant - Runs on Alliant minisupercomputers
Amdahl - Runs on Amdahl mainframes
Cray - Runs on a Cray supercomputer with CSOS
Cray2 - Runs on a Cray2 supercomputer with UniCos
Convex - Runs on Convex minisupercomputers
DEC - Runs on DEC Risc Workstations
Mac - Runs on Mac
PC - Runs on PCs or PC compatibles running DOS
SGI - Runs on Silicon Graphics systems
Sun - Runs on Sun Microsystems Workstations
Hardware required:
AT&T-4425 - Requires an AT&T 4425 terminal
CDROM - Requires a cdrom player
dj500 - Requires HP DeskJet 500 printer
MIDI - You will need a MIDI to run this
HPLJ - HP Laserjet II or III printer or compatible
General Notes:
!16BIT - Don't try to to run on a 16 bit machine (8088,186,286)
32BIT - Requires 32 Bit Architecture
24BIT - Requires 24 Bit Color Graphics card
--------------------
4. Guidelines for submitting source for publication
To make life easier for both the readers of this newsgroup and myself, I
request that all submissions follow the guidelines described below. Not
following these guidelines may result in longer delays, since some
things *must* be fixed for news to accept the submission. Others must
be fixed so that I can spend time processing submissions rather than
responding to flames. ;-)
- Software is mailed to the csr submission address
(comp-sourc...@sterling.com)
or posted to the
comp.sources.reviewed
newsgroup in small (< 80K) shar files.
- All software packages must include:
a. An introduction to the package for the moderator containing:
1. Information on any hardware or software dependencies. (See
Environment above)
2. Any suggestions for or limitations on the review period.
3. A brief description of the package suitable for inclusion in
the CFR.
b. A makefile, or makefile equivalent.
c. Directions for building and installing the software
d. Manual Page(s) or other documentation detailing how to use
the software.
Please do not package executable programs and sources in the same
submission. Executable binary programs are inherently system-dependent,
and therefore should be posted to a system-specific "binaries" group.
As a special case, Un*x executables should NEVER be posted to Usenet.
Please keep source filenames to 12 or fewer characters in length.
Not everyone has long filenames... :-( And for those of us that do,
ar limits libraries members to 15 characters.
I have been receiving a number of messages with uucp addresses that are
not reachable. Please specify a domain based address if possible. If
you do not know what your domain based address is, please ask your site
admin or the site administrator of your upstream news feed.
Other considerations:
The posting software I use reads the submission and prompts me for all
the information needed to post. It uses information supplied by you in
the header as the default information. The Subject: line is usually
munged although your supplied information is used. Auxiliary headers
supplied in the submission are used where appropriate.
The following headers are passed through the software untouched.
Keywords:, Organization:, Reply-To: and Summary:
If you supplied them, they are put into the posted article.
Again, *please* let me know what should go in the Environment: line. If
you don't, I have to try to determine what is accurate. Sometimes it's
hard to do without full blown testing. Archive-name:, Subject:, and
Environment: are the three pieces of information that I really need.
Otherwise I get to make up what is supplied there. Don't complain to me
if I get it wrong and you didn't take the time to send me the correct
information in the first place... If you did send me the information and
I got it wrong, give it to me with both barrels...
-----------------
5. Patches Handling
Patches to previously published/archived packages are accepted but
initiate an abbreviated review cycle for that package. (Note - see the
guide for submitters for how patches should be handled prior to
initial publication). Patches are handled as swiftly as possible.
Authors of sources posted to c.s.reviewed should send all patches to me
so that I can initiate a review of the patched/new version. This
has not been done in the past in other sources groups and has lead to
lost patches. If the patches must get out *real* fast, then post them
to comp.sources.bugs and other appropriate newsgroups and send me a copy
at the same time. That way they will be available when they are needed
in the future. Again, patches receive priority processing so make sure
I get them.
I will not to post patches that are not sent by the author of the
original posting unless special arrangements have been made with the
author. Please send your unofficial patches to the author so that the
author can incorporate them into their posting's baseline. Unofficial
patches can be posted to comp.sources.bugs as a method of letting the
community use the fix or enhancement during the interim.
It is up to the author to determine if there have been major enough
changes to warrant a complete reposting. This may be necessary if the
size of the patches exceeds the size of the source but in most cases
only patches are posted. Total repostings should be treated as an
initial posting. What follows pertains to patches...
1. When patches are submitted, they should be in context diff
format. Patches can be made with diff -c on 4.x BSD based
machines and with diffc on others. Diffc can be found in
volume 1 of comp.sources.unix archives. GNU diff can also be
used to create context diffs.
2. Please assure that the patches are relative to the source
directory. In otherwords, cd into the new source directory
and create the patches by specifying "old-source-dir" then "."
when running the diff. This makes it easier to apply the
patches as there is no confusion concerning reversed patches
or directory path name changes.
3. A patch to patchlevel.h should be done to reflect that the
patch has been applied if a patchlevel.h existed in the initial
posting. If one was not included initially, maybe now is a
good time to consider including one... :-)
4. Include information about which previously posted issues
the patch pertains to if they were initially posted to c.s.reviewed.
For more information on patch see patch.man in util/patch/patch.man
in the X11 Release 4 distribution or in volume7 of the comp.sources.unix
archives.
------------------------
6. Special services
One way to solve the problem of an announcement not going out the same
day as the posting it announces is to send the announcement to me under
separate cover. This should really only be done after the review is
complete an the package accepted for posting. Please, it slows things
down if I have to break apart submission apart to get at the file.
Please supply instructions as to which newsgroup(s) it should be posted
in, and I will insure that both go out the same day, if possible. (If one
of the other newsgroups is also moderated, there's not a whole lot I can do
about it.) The same goes for binaries and/or other material associated with
a source; send it under separate cover and tell me what to do with it, and I
will try to arrange for them to all go out at the same time.
--------------------
7. Reporting and tracking bugs.
The following information applies ONLY to software which has been previously
published and archived. See the guides for reviewers and submitters for
information on reporting bugs during the review process.
You *should* subscribe to comp.sources.bugs.
Sometimes, when new versions of previously-published software is made
available, just patches are put out. Usually the patches are in the
form of shar files containing input for the "patch" program, new files,
etc. Sometimes complete new versions are put out. Which method is used
depends on the poster and the moderator. Minor updates must be in patch
form and should update a patchlevel.h file. Major updates should follow
the guidelines for initial postings.
To report bugs, contact the person listed in the Submitted-by: header.
Often there is a contact address in a README file, too. I *do not*
maintain the sources I moderate, so don't send your bug reports to me.
That just forces a delay in the right person getting them as I will
forward them on to the author. Likewise, I normally do not post patches
for a package from anyone except the author. If you have patches you
would like to see included in the package, send them to the person
listed in the Submitted-by: header.
------------------------
8. Newsgroup Status Information.
You should subscribe to comp.sources.d.
In some newsgroups, postings such as "I will be out of town..." and
"What's in the queue to post..." have been posted as INF postings with
an Archive-name: of /dev/null or .junk. I will not post these types of
messages to c.s.reviewed due to the limited amount of time that information
of this type is useful. These kinds of messages are being posted to
comp.sources.d as the need arises. In this manner, the informational
c.s.d postings expire as they should and will not be archived taking
up disk space forever.
--------------------
9. Accessing the archives
The official archive sites for comp.sources.reviewed are currently only
ftp.sterling.com and ftp.uu.net.
The complete archives will get fairly large with an average volume taking up
four megabytes.
Some sites below offer to send tapes through the mail. For those sites,
send the appropriate type of tape media WITH RETURN POSTAGE and RETURN
MAILER. Tapes without postage or mailer will not be returned. No other
methods (COD, etc.) are available; please don't ask. You will need to
contact the individual archive sites to determine if they can support
your type of media.
There a couple sites that provide email access to their archives. Please
use them when you need to locate a missing issue. Please don't ask me
for missing issues. Included at the end of this article are detailed
instructions on how to access the archives. More sites will be listed
there in the future. You can always check with archie.
I have as complete a set of archives as I have found. I have all the
issues listed in the indexes except for the first volume. If you have
articles from volume 1 please send me a list of articles so I can see
if there are some I do not have.
If anyone has an article that was posted to the group that is not listed
in the indexes, please send me the information and a copy of the article
so that I can update the archive sites that I maintain.
--------------------
10. Archive access via ftp
If an archive site provides "anonymous FTP" access, sites directly on
the Internet can use the "ftp" program to get at sources. Sites which
aren't on the Internet can not use ftp to retrieve this information. And
no, just having the ftp program does not mean that you have access to
the Internet.
You should check with a local system administrator to find out the
details of using ftp. On most systems and to most archive sites, the
following will work: type the command "ftp system.domain" (example:
"ftp ftp.uu.net" -- case does not matter), enter "anonymous" when it
asks for a user name, and enter *your* Internet email address as the
password. If "ftp" says that the system doesn't exist, check your
spelling -- if the system name is spelled correctly, look for an IP
address for the archive site and badger your system administrator to
install a version of ftp which knows about nameservers. You should
also be warned that some systems (like uunet) will not accept FTP
connections from sites not registered with a nameserver.
Once you're logged in to the archive system, you'll get a prompt that
looks like "ftp>". It may not be identical, since it's possible to change
the ftp prompt with a command in many versions of ftp.) At this point,
you can use "cd" to change directories, "ls" or "dir" to list files, and
"get" to retrieve them. For sources archives, it's not necessary to
worry about file types unless the files are compressed. In that case,
you must use the "binary" command for Unix or VMS hosts and "tenex" on
Tenex (TOPS-10, TENEX, TOPS-20/TWENEX) hosts.
*** Not switching the file type can result in a garbled file, especially
*** on Tenex hosts, which do not store binary data the same way as Unix
*** hosts.
To disconnect from the archive site, enter the "bye" command.
--------------------
11. Archive access via uucp
UUCP archives aren't as standardized as FTP archives. Check the archive
list for the account name and password to use, and ask your system
administrator to arrange to be able to poll the archive site. (If
s/he/it refuses, you're stuck.)
The "uucp" command is used to request files from a UUCP archive. Unlike
FTP, UUCP does not (usually) do the transfer immediately. This is
because most UUCP sites must be called over telephone lines. Long
distance calls are usually made in the early morning hours to reduce
costs.
Since you can't look around in the archives, you must know the pathname
of an article to be retrieved. Archives generally have an index file
available via UUCP. It's a real good idea to retrieve this file before
getting anything from the archive, since things can move around without
warning.
The command to retrieve a submission looks like
uucp archivesite!path/to/file destination-location
"archivesite" is the name of the archive site, and "path/to/file" is the
pathname listed in the archive index for that site. Please note, for
security reasons, it is not usually possible to specify wildcards (?, *,
[], or ~name) in the pathname. Also, while more recent versions of uucp
allow a uucp command to traverse multiple systems, for security and
resource reasons this is usually disabled. In both cases you won't find
out until after the archive site has been called.
--------------------
12. Archive access via email
Some archive sites have mail servers that will accept mail from you and
mail back files from the archive. There are no standards here; however,
it's usually safe to mail a message containing the single word "help" to
the mail server. Check the archive list for more information.
***********************************************************************
Do not use the reviewers mailing lists for retrieving archived
software. I do not and will not garrentee that the version you
may find on a still active list is the version that was posted
and archived. These mailing lists are only for use in retrieving
software during the review periods by people REVIEWING the software.
************************************************************************
As an example, to receive the index from the comp.sources.reviewed archives
on uunet, send the following one line as the body of a message to
uunet!netlib.
send index from comp.sources.reviewed
IMPORTANT TO REMEMBER: Mail Archive Servers (MAS) are there for the
convenience of the community and are *easily* abused. *Please* do not
request to have a MAS send you GCC or X11R5. A good deal of this
traffic goes through intermediate sites that have not advertised this
service. You would be taking resources away that are not yours to take.
This type of irresponsibility will do nothing but irritate the sites
that feed you and may jeopardize your facilities in the process.
--------------------
13. Extracting a retrieved archive member
If the article came from an archive site, it may be compressed. If it
was sent by a mail server, it may also be uuencoded. Compressed files
have an extension of ".Z". Uuencoded files can be recognized by a line
saying "begin 666 filename", followed by lines of what looks like random
gobbledygook. (If a mail server splits a file into multiple parts, you
may just have the gobbledygook. In this case, the server will include a
message saying which part of the file it is, and will tell you how to
combine them.)
To extract a uuencoded file, type the command "uudecode filename". This
creates a (binary, usually compressed) file in the current directory.
To extract a compressed file, type the command "uncompress filename".
The ".Z" extension is removed from the file. The original, compressed
file will be removed as part of this operation.
After doing this, you should be left with the requested article exactly
as it was stored in the news spool directories. The file contains a news
header, a description (usually), and a "shell archive" ("shar"). Move
to an empty directory (important!) and unpack the archive. Some systems
have a command "unshar" to unpack these files; if yours does, use it.
Otherwise, you can use an editor to remove the header, then just say
"sh filename". I use a small (one line) shell script:
sed '1,/^[#:]/d' $1 | sh
which should handle anything (I hope!) in the c.s.reviewed archives. I
and the reviewers do attempt to confirm that a shell archive contains
nothing dangerous, but if you unpack as root and the archive removes
your /etc directory or something equally ugly and unpleasant, I don't
want to hear about it. Unpack shell archives as an unprivileged user.
Once you've unpacked the archive, you're on your own. Keep the header
from the submission handy, in case you can't figure out what's going on.
The address specified in the "Submitted-by:" line can be used to contact
the author of the program.
------------------------
14. Becoming an archive site
If you collect comp.sources.reviewed postings and are willing and able to
make your collection available to other people, please let me know.
Benefits include the undying gratitude of your colleagues, and a promise
from me to try to make sure you never lose an article.
If you can provide access to your archives send me some email and I'll
get you some publicity... :-) If you need automated tools to build and
maintain your archives, I have those too. :-) If you need a tape of the
archives to get you jump-started, let me know.
PLEASE NOTE: Mail Archive Servers are there for the convenience of the
community but are too easily abused. Because of this, I can not, in
good conscience, list archive sites whose sole access is email based.
If you can't supply anonymous ftp as a secondary method for accessing
your archives then consider uucp. It is easy enough to set up a uucp
account for archive access with the appropriate security to protect your
other system resources.
--------------------
15. Listing of archive sites in no particular order
Here is what each field means:
Site: The name of the site nice enough to act as an archive site.
Contact: The name of the person to contact and their mail address
Location: The general area of the world the site is located in.
Modems: What types of modems are available.
UUCP: Type of UUCP access is available.
FTP: Type of FTP access is available.
Mail Server: Account address of the automated mail server if available.
Additional: Additional information pertaining to accessing the archive.
NA - Not Available
************************
U S A - EASTERN
************************
Site: uunet.uu.net/ftp.uu.net
Contact: Kent Landfield (ke...@uunet.uu.net)
Location: Fairfax, VA
Modems: Telebit
UUCP: uunet uucp customers and 1-900-GOT-SRCS
FTP: anonymous ftp (please use ftp.uu.net for ftp access)
Mail server: netlib@uunet
Additional: UUNET is keeping archives in ~ftp/usenet/comp.sources.reviewed
And it will be a mirror of the ftp.sterling.com archives.
For more information concerning the archives on uunet, send
an email message net...@uunet.uu.net with the following as the body
of the message:
send index from comp.sources.reviewed
You can also use 1-900-GOT-SRCS to access this archive.
************************
U S A - CENTRAL
************************
Site: ftp.sterling.com (ftp)
Contact: Kent Landfield (kent_la...@sterling.com)
Location: Omaha/Bellevue, NE
Modems: Telebit
UUCP: On request
FTP: Anonymous FTP
Mail server: NA
Additional: This archive site has both Volume-Issue and Package
archive views.
----------------
16. How to become a reviewer
In order to become a CSR reviewer all you need to do is retrieve the
package for review, subscribe to the package mailing list, and mail
your review to the moderator at comp-sourc...@sterling.com.
(See below for instructions on how to use the mail server).
To be notified of packages available for review via E-mail subscribe to
csr-re...@ftp.sterling.com mailing list (See below for how to
subscribe).
To subscribe to the package review list and have the package automatically
mailed to you send a message to:
csr-<package_name>-req...@ftp.sterling.com
with:
Subject: subscribe
To get a package for review (if you lost the first or a new version is made
available) send a message to:
csr-<package_name>-req...@ftp.sterling.com
with:
Subject: archive get part1 part2 ... partn
To correspond with the package author and other reviewers send mail
to: csr-<package_name>@ftp.sterling.com
If you have trouble with the mail server send a message to:
csr-<package_name>-req...@ftp.sterling.com
with:
Subject: help
And it will send you a help file.
To help you in your reviews a guide for reviews has been developed.
This is available both as the third section of this informational
posting and from the comp-sources-reviewers mailing list. To retrieve
from the mailing list send a message to:
csr-review...@ftp.sterling.com
with:
Subject: archive get csr.guide.rev
----------------
17. Credits
I`d like to thank the following people for assisting me in moderating the
group. First, I'd like to thank Kent Landfield <ke...@sterling.com> for
providing me with the information and software to moderate the group. Most
all the words in this document were shamefully stolen from the INF1 posting
in comp.sources.misc. Also, I like to thank him for setting up and
maintaining the c.s.reviewed archives. (By the way Kent wrote this
also ;-))