koreth@panarthea.ebay.sun.com (Steven Grimm) (08/15/90)
Submitted-by: koreth@panarthea.ebay.sun.com (Steven Grimm)
Posting-number: Volume 12, Info 1
Archive-name: intro
This is the first of three introductory articles about comp.binaries.atari.st.
This one describes how to submit binaries to the newsgroup. A companion
article lists all previously-published binaries, and a third article explains
how to retrieve and unpack binaries posted by others.
I am always looking for suggestions on how to improve the usefulness
of the newsgroup, and can be contacted as listed below.
-- Steven Grimm
koreth@panarthea.ebay.sun.com
--------------------
Subject: Submitting binaries for publication
Items intended for posting or queries and problem notes should be sent to
atari-binaries@panarthea.ebay.sun.com. If you are on a UUCP-only site, you
can send them to {backbone}!sun!ebay!panarthea!atari-binaries.
If you're in Europe, you can send binaries to the European submoderator,
Jan-Hinrich Fessel, at unido!atari-binaries (or, if you're a masochist,
atari-binaries@unido.informatik.uni-dortmund.de.) He will test them and
forward them to me. Submitting to him saves net bandwidth, so it's
encouraged.
If you want verification of arrival, so say in a cover note, or at the
beginning of your submission, if it is small. I try to verify that a
program works, and if I can't get it to work, I may hold up posting it
for a couple of days. Please note that, except in rare cases, software
without documentation will not be published. The backlog from receipt
to posting varies from one to four weeks depending mostly on the set
of submissions currently in my queue.
If you are submitting both sources and binaries, PLEASE send the two
separately. If I have to separate your sources from your binaries by
hand, your submission will most likely sit on the back burner for a
while.
Also, as of volume 8, I will only accept binaries packed with an archiver
for which source code is widely available. For the time being, this pretty
much means arc, zoo, and lharc. If you want to use a nifty new archiver,
make the source code available to the public (posting to comp.sources.atari.st
is fine.) I reserve the right to repack binaries with another archiver if
the other archiver saves a significant amount of space, or has other
advantages.
If you're submitting a demo of a commercial program, or a shareware program,
please keep the amount of advertising to an absolute minimum. The net
gods become angry when people try to use the net as a free advertising
medium, and I'd like to keep comp.binaries.atari.st out of trouble. If
you want to solicit orders, do it in a README file or an About... dialog
box, not in a message that comes up every time the user does something.
In other words, treat the net like a PBS station (apologies to those
outside the US.) I will not accept programs which I feel are excessively
commercial. I'm aware that commercial demos and shareware are often very
useful (to the users on the net,) which is why I allow them at all.
--------------------
Subject: The structure of comp.binaries.atari.st articles
Each posting in comp.binaries.atari.st is called an "issue"; there are
roughly 100 issues to a volume. The division is arbitrary and may vary.
There are two types of articles in comp.binaries.atari.st: binaries and
"information postings." They can be distinguished by the subject line:
Subject: v12INF2: Index and other info
This first word in the title identifies this as the third info posting of
volume six. Similarly, the subject line shown below:
Subject: v12i081: deadwrtr -- Ouija-word processor
identifies this as the 81st binary article in Volume 12. Large programs are
broken up into smaller pieces, and have subject lines that look like
this:
Subject: v12i041: zx81 -- Timex/Sinclair emulator part04/39
Certain information about the system configuration required to use the
program is given on the keywords line.
Keywords: uuencode, 1meg, medium, high
This means that the program requires at least one meg of RAM and runs in
medium or high resolution. Following is a list of keywords; new ones may
be added as needed. They are mostly self-explanatory.
uuencode - program is uuencoded (UNIX uudecode required to unpack)
uue - program is uuencoded (ST uud required to unpack)
arc - program is archived (arc required to unpack)
zoo - program is a zoo archive (zoo required to unpack)
lharc - program is an lharc archive (lharc required to unpack)
high - high resolution
medium - medium resolution
low - low resolution
1meg - needs 1 meg of RAM
The first few lines of an article are auxiliary headers that look like this:
Submitted-by: jackt@atari.UUCP (Jack Tramiel)
Posting-number: Volume 12, Issue 80
Archive-name: rsn
The "Submitted by" is the author of the program. If you have comments about
the binaries published in comp.binaries.atari.st 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 (backbone) site.
The "Reply-To:" header line in the article's main header points to the
submitter, to make commenting about binaries easier.
The second line repeats the volume/issue information for the aide of notes
sites and automatic archiving programs.
The Archive-name is the "official" name of this program in the archive. Large
postings will have names that look like this:
Archive-name: desktop/part01
Since most archive sites run UNIX, articles are given UNIX-style filenames
rather than ST-style filenames. I do make an effort to keep filenames to
8 characters or smaller, however.
--------------------
Subject: Reporting and tracking bugs and patches to postings
Updates to programs are usually announced in comp.sys.atari.st. When
large changes are made to a program, the entire thing will be reposted
to comp.binaries.atari.st.
To report bugs, contact the person listed in the Submitted-to header.
Often there is a contact address in a README file, too. I do not maintain
the programs I moderate, so don't send your bug reports to me.
If the program documentation mentions some file that isn't included in
the posting (for instance, a font editor's documentation might refer to
some sample fonts), contact the submitter, not me. I post articles in
their entirety, so if it isn't posted, I probably don't have it.