home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / games / volume15 / intro15 < prev    next >
Internet Message Format  |  1993-01-27  |  13KB

  1. Path: uunet!ogicse!zephyr.ens.tek.com!master!saab!billr
  2. From: billr@saab.CNA.TEK.COM (Bill Randle)
  3. Newsgroups: comp.sources.games
  4. Subject: v15INF1:  intro15 - Introduction to comp.sources.games
  5. Message-ID: <3635@master.CNA.TEK.COM>
  6. Date: 23 Sep 92 15:59:58 GMT
  7. Article-I.D.: master.3635
  8. Sender: news@master.CNA.TEK.COM
  9. Lines: 272
  10. Approved: billr@saab.CNA.TEK.COM
  11.  
  12. Submitted-by: Bill Randle <billr@saab.CNA.TEK.COM>
  13. Posting-number: Volume 15, Info 1
  14. Archive-name: intro15
  15. Supersedes: Volume 14, Issue 1
  16. Environment: 
  17.  
  18.  
  19.  
  20. This is the first of several introductory messages about comp.sources.games:
  21.    *1. How to submit sources to comp.sources.games.
  22.     2. List of sources posted to this newsgroup arranged numerically
  23.     by volume/issue number.  It provides a listing of the
  24.     Volume/Issue, the Archive-name and the Subject for each
  25.     posting. [Part 1/2: vols 1-7]
  26.     3. List of sources posted to this newsgroup arranged numerically
  27.     by volume/issue number.  It provides a listing of the
  28.     Volume/Issue, the Archive-name and the Subject for each
  29.     posting. [Part 2/2: vols 8-14]
  30.     4. List of sources posted to this newsgroup arranged
  31.     alphabetically by name.  It provides a listing of the the
  32.     Archive-name, Volume/Issue, and the Subject for each posting.
  33.     [Part 1/3: a-l]
  34.     5. List of sources posted to this newsgroup arranged
  35.     alphabetically by name.  It provides a listing of the the
  36.     Archive-name, Volume/Issue, and the Subject for each posting.
  37.     [Part 2/3: m-o]
  38.     6. List of sources posted to this newsgroup arranged
  39.     alphabetically by name.  It provides a listing of the the
  40.     Archive-name, Volume/Issue, and the Subject for each posting.
  41.     [Part 3/3: p-z]
  42.     7. List of the patches that have been posted in c.s.g.
  43.     8. Index of sources in the games archive on saab.  (This
  44.     includes some games that have not been posted to the c.s.g.
  45.     newsgroup (e.g. X-windows games). [Part 1/2: a-s]
  46.     9. Index of sources in the games archive on saab.  (This
  47.     includes some games that have not been posted to the c.s.g.
  48.     newsgroup (e.g. X-windows games). [Part 2/2: t-z]
  49.    10. The list of archive sites and how to contact them.
  50.  
  51. There are *many* things covered in this posting -- each new topic is
  52. preceded by a Subject: line.  If you get bored reading a particular
  53. section, fast forward to the next Subject: line and read that one.
  54. Please don't submit sources without having read -everything- in this
  55. file (you'll be tested and graded later :-).
  56.  
  57. I am always looking for suggestions on how to improve the usefulness
  58. of the newsgroup.  Please do not hesitate to send suggestions to
  59. billr@saab.CNA.TEK.COM.
  60.  
  61. --------------------
  62. Subject:  The structure of comp.sources.games articles
  63.  
  64. Each posting in comp.sources.games is called an "issue"; there are roughly 100
  65. issues to a volume.  The division is arbitrary, and has varied in
  66. the past.  There are two types of articles in comp.sources.games; sources
  67. and "information postings."  They can be distinguished by the subject
  68. line:
  69.     Subject:  v03INF1:  Introduction to comp.sources.games
  70.  
  71. This first word in the title identifies this as the first info posting of
  72. volume three.  Similarly, the subject line shown below:
  73.  
  74.     Subject:  v01i060:  war - intergalactic simulation, Part01/40
  75.  
  76. identifies this as the 60th source article in Volume 1.  All sources are
  77. broken up into pieces.  This is done so that there could be a proper storage
  78. directory when patches are issued. This is part 1 of a 40 part posting. 
  79.  
  80. The first few lines of an article are auxiliary headers that look like this:
  81.  
  82.     Submitted-by: root@freeware.ATT.COM
  83.     Posting-number: Volume 7, Issue 82
  84.     Archive-name: monopoly/Part01
  85.     Environment: Unix
  86.  
  87. The "Submitted-by" is the author of the program.  IF YOU HAVE COMMENTS ABOUT
  88. THE SOURCES PUBLISHED IN COMP.SOURCES.GAMES, THIS IS THE PERSON TO CONTACT.
  89. When possible, this address is in domain form, otherwise it is a UUCP bang
  90. path relative to some major site such as "uunet."
  91.  
  92. The second line repeats the volume/issue information for the aide of NOTES
  93. sites and automatic archiving programs.
  94.  
  95. The Archive-name is the "official" name of this source in the archive.  Large
  96. postings will have names that look like this:
  97.  
  98.     Archive-name: zork/Part01
  99.  
  100. Please try to use this name when requesting that sources be mailed to you.
  101. Also, note that the "part number" given in the title, and the archive name
  102. given in the auxiliary header need not be identical.
  103.  
  104. The Environment is a few key words describing the operating environment
  105. required by the program. Typical keywords are: Unix, MS-DOS, VMS, X11,
  106. SunView, Curses, etc.
  107.  
  108. -----------------
  109. Subject: Patches Handling
  110.  
  111. Patches will be handled as swiftly as possible. Authors of sources posted
  112. to c.s.g should send all patches to me so that I can post them back through
  113. the newsgroup in order that the patches can be archived. This has not been
  114. done in the past in other sources groups and has lead to lost patches. If
  115. the patches must get out *real* fast, post them to comp.sources.games.bugs
  116. and send me a copy at the same time so that they will be available when
  117. they are needed in the future.
  118.  
  119. To support the tracking of patches, the Patch-To: line is used in c.s.g.
  120. The Patch-To: line exists for articles that are patches to previously posted 
  121. software. The Patch-To: line only appears in articles that are posted, 
  122. "Official", patches. The initial postings would not contain the Patch-To: 
  123. auxiliary header line.
  124.  
  125. Patch-To: syntax
  126.     Patch-To: package-name: Volume X, Issue x[-y,z]
  127.  
  128. Patch-To: examples. These are examples and do not reflect the
  129. accurate volume/issue numbering for rkive.
  130.  
  131. In the first example, the article that contains the following line
  132. is a patch to a single part posting.
  133.     Patch-To: rkive: Volume 22, Issue 122
  134.  
  135. This example shows that the 122-124 indicates the patch applies to
  136. a multi-part posting. The '-' is used to mean "article A through article
  137. B, inclusive..
  138.     Patch-To: rkive: Volume 22, Issue 122-124
  139.  
  140. If a patch applies to multiple part postings that are not consecutive, the
  141. ',' is used to separate the part issue numbers. It is possible to mix both
  142. ',' and '-' on a single Patch-To: line.
  143.     Patch-To: rkive: Volume 22, Issue 122,125,126,127
  144.     Patch-To: rkive: Volume 22, Issue 122,125-127
  145.  
  146. If a new release is posted instead of a large set of patches, then the
  147. posting will ontain a Supercedes: header line with a format similar to
  148. the Patch-To: header.
  149.  
  150. Supercedes: syntax
  151.     Supercedes: package-name: Volume X, Issue x[-y,z]
  152.  
  153. Supercedes: examples
  154.     Supercedes: rkive: Volume 22, Issue 122-124
  155.     Supercedes: rkive: Volume 22, Issue 122-125,127
  156.  
  157. --------------------
  158. Subject: Reporting and tracking bugs.
  159.  
  160. You should subscribe to comp.sources.games.bugs.
  161.  
  162. Sometimes, when new versions of previously-published software is available,
  163. just patches are put out, usually in the form of shar files containing
  164. input for the "patch" program, new files, etc.  Sometimes complete new
  165. versions are put out.  Which method is used depends on the poster and
  166. the moderator.  Minor updates must be in patch form and update the 
  167. patchlevel.h file.  Major updates should be the guidelines for postings.
  168.  
  169. To report bugs, contact the person listed in the Submitted-by header.
  170. Often there is a contact address in a README file, too.  I do not maintain
  171. the sources I moderate, so don't send your bug reports to me.
  172. Likewise, I normally do not post patches for a package from anyone
  173. except the author. If you have patches you would like to see included
  174. in the package, send them to the person listed in the Submitted-by
  175. header. If the original author is incommunicado I will consider posting
  176. patches submitted by other people.
  177.  
  178. --------------------
  179. Subject: Submitting source for publication
  180.  
  181. Items intended for posting or queries and problem notes should be sent to
  182. games@saab.CNA.TEK.COM
  183.  
  184. If you want verification of arrival, say so in a cover note, or at the
  185. beginning of your submission, if it is small.  I try to verify that a
  186. program works, and if I can't get it to work, I may hold up posting it
  187. for a couple of days.  Please note that, except in rare cases, source
  188. that doesn't meet the guidelines will not be published.  The backlog
  189. from receipt to posting varies from one to three weeks depending mostly
  190. on the set of submissions currently in my queue and my current work load.
  191.  
  192. -------------------
  193. Subject: Guidelines
  194.  
  195. To make life easier for both myself and the users of the comp.sources.games
  196. newsgroup, I request that all submissions follow the following guidelines.
  197.  
  198. Initial Submissions:
  199.     1.  Source filenames need to be 12 or fewer characters in length.
  200.     2.  Source files need to be less than 50K bytes in size.
  201.     3.  A Makefile is highly desirable. 
  202.     4.  A manual page is desirable.
  203.     5.  A README file is required. This should contain a brief
  204.         description of what the posting is and any special
  205.         considerations in building it. The README should
  206.         also contain a list of authors and the distribution
  207.         and copying policy. 
  208.  
  209. Updates, patches, etc.:
  210.     It is up to the author to determine if there have been major enough
  211.     changes to warrant a complete reposting. This may be necessary if the
  212.     size of the patches exceeds the size of the source, but in most cases
  213.     only patches are posted. Total repostings should be treated as an 
  214.     initial posting. What follows pertains to patches...
  215.  
  216.     1.  When patches are submitted, they should be in context diff 
  217.         format.
  218.     2.  A patch to patchlevel.h should be done to reflect that the
  219.         patch has been applied.
  220.     3.  Include information about which previously posted issues 
  221.         the patch pertains to if they were initially posted to c.s.g.
  222.  
  223.     The patch program is currently at version 2.0 patchlevel 12, and may
  224.     be obtained via anonymous ftp from jpl-devvax.jpl.nasa.gov.  The
  225.     original 2.0 distribution and the first 11 patches are in the
  226.     comp.sources.unix archives on uunet.  The exact patchlevel is
  227.     probably not important for applying most patches, but you should
  228.     have some variety of 2.0, as it supports features like creating new
  229.     files and adding/subtracting lines with only one copy of the context,
  230.     as are created by recent varieties of diff.
  231.  
  232.     Patches can be made with diff -c on many machines and
  233.     with diffc on others. Diffc can be found in volume 1 of comp.sources.unix
  234.     archives. GNU diff can also be used to create context diffs.
  235.  
  236. ------------------------
  237. Subject: Becoming an archive site
  238.  
  239. If you collect comp.sources.games postings and are willing and able to make
  240. your collection available to other people, please let me know.  Benefits
  241. include the undying gratitude of your colleagues, and a promise from me to
  242. try to make sure you never lose an article.  
  243.  
  244. --------------------
  245. Subject: Accessing the archives
  246.  
  247. The complete archives are fairly large; an average volume is three to
  248. four megabytes.
  249.  
  250. There are several active archive sites around the net, but more are always
  251. welcome - especially outside the US.
  252.  
  253. Some sites below will send tapes through the mail.  For those sites, send
  254. a 1/2" mag tape WITH RETURN POSTAGE and RETURN MAILER.  Tapes without
  255. postage or mailer will not be returned.  No other methods (COD, etc.) are
  256. available; please don't ask. Other sites may make 1/4" mag tapes, 8mm
  257. mag tapes or floppy disks. It doesn't hurt to ask.
  258.  
  259. --------------------
  260. Subject: Editorial comments
  261.  
  262. I generally accept any game (or entertaining diversion) software without
  263. regard to host architecture or operating system. There are some exceptions,
  264. as there are specific newsgroups for many architectures. Thus if your
  265. game is IBM PC specific or Mac or Atari only, it is generally better
  266. to post it in the comp.sources.<favorite architecture> newsgroup (if
  267. it exists). The other exception is games that are specific to the
  268. X-Windows windowing system. They should be generally posted to the
  269. comp.sources.x newsgroup. If the moderator will not accept it for
  270. posting there, send it to me. Games that utilize more than one display
  271. system, e.g. X11 and SunView should be sent to me. Although there is
  272. a comp.sources.sun newsgroup, SunView based games have historically
  273. been posted in the comp.sources.games newsgroup.
  274.  
  275.  
  276.     "Top 6 pet peeves of the comp.sources.games moderator."
  277.  
  278. 1.   Programs that don't compile right the first time.
  279. 2.   Programs that don't execute right the first time.
  280. 3.   Patches that don't apply correctly.
  281. 4.   Individual source files larger than ~50K bytes.
  282. 5.   Submissions that do not contain a README or Makefile file.
  283. 6.   Submissions that do not contain a man page.
  284.