Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/x/volume8/intro8

Internet Message Format | 1993-04-28 | 11KB

From: [e-mail] (Dan Heller)
Newsgroups: comp.sources.x
Subject: v08INF1: Introduction to comp.sources.x
Message-ID: <[e-mail]>
Date: 27 Jun 90 06:32:54 GMT
Approved: [e-mail]

Submitted-by: Dan Heller <[e-mail]>
Posting-number: Volume 8, Info 1
Archive-name: intro8

This is the first of two introductory messages about comp.sources.x.
There are *many* things covered in this posting -- each new topic is
preceded by a Subject: line.  If you get bored reading a particular
section, fast forward to the next Subject: line and read that one.
Please don't submit sources without having read -everything- in this
file (you'll be tested and graded later :-).

Most of all, this posting describes how to submit sources to comp.sources.x,
where the archive sites are, and how to contact them.  The second lists
the sources that have been published in this newsgroup.

NOTE 1:
    Many people are submitting sources that do not have an Imakefile
    or a patchlevel.h.  You *must* provide these!  I no longer have the
    time to create them for you.  Further submissions that do not have
    these files will be rejected.

NOTE 2:
    Patches *must* contain an update to patchlevel.h and indicate which
    volume and issue numbers that precede this patch.  This includes both
    the original posting and previous patches.

--------------------
Subject:  The structure of comp.sources.x articles

Each posting in comp.sources.x is called an "issue"; there are roughly 100
issues to a volume.  The division is arbitrary, and has varied greatly in
the past.  There are two types of articles in comp.sources.x; sources
and "information postings."  They can be distinguished by the subject
line:
    Subject:  v03INF1:  Introduction to comp.sources.x

This first word in the title identifies this as the first info posting of
volume three.  Similarly, the subject line shown below:

    Subject:  v01i060:  select: a selection widget, Part01/01

identifies this as the 60th source article in Volume 1.  All sources are
broken up into pieces.  This is done so that there could be a proper storage
directory when patches are issued. This is part 1 of a 1 part posting.

    Subject:  v01i056:  xphoon: Show phase of the Moon on root window, Part01/04

The first few lines of an article are auxiliary headers that look like this:

    Submitted-by: [e-mail]
    Posting-number: Volume 7, Issue 82
    Archive-name: new-Xlogin/part01

The "Submitted-by" is the author of the program.  IF YOU HAVE COMMENTS ABOUT
THE SOURCES PUBLISHED IN COMP.SOURCES.X, 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.

The Archive-name is the "official" name of this source in the archive.  Large
postings will have names that look like this:

    Archive-name: xdvi/part01

Please try to use this name when requesting that sources be mailed to you.
Also, note that the "part number" given in the title, and the archive name
given in the auxiliary header need not be identical.

-----------------
Subject: Patches Handling

Patches will be handled as swiftly as possible. Authors of sources posted
to c.s.x should send all patches to me so that I can post them back through
the newsgroup in order that the patches can be archived. 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, post them to comp.sources.bugs and
send me a copy at the same time so that they will be available when they
are needed in the future.

To support the tracking of patches, the Patch-To: line is used in c.s.x.
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 would 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 22, Issue 122

This example shows that the 122-124 indicates the patch applies to
a multi-part posting. The '-' is used to mean "article A through article
B, inclusive..
    Patch-To: rkive: Volume 22, Issue 122-124

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 22, Issue 122,125,126,127
    Patch-To: rkive: Volume 22, Issue 122,125-127

--------------------
Subject: Reporting and tracking bugs.

You should subscribe to comp.sources.bugs.

Sometimes, when new versions of previously-published software is available,
just patches are put out, usually in the form of shar files containing
input for the "patch" program, new files, etc.  Sometimes complete new
versions are put out.  Generally, minor updates should be in patch form
and update the patchlevel.h file.  Major updates usually indicate that
there have been so many changes that the patches outweigh the size of the
new source or that the number of patch levels grows so large that people
are rarely up to date.  If it's been a year since the last major posting,
it is a candidate for being reposted.

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.
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.

--------------------
Subject: Submitting source for publication

Items intended for posting or queries and problem notes should be sent to
[e-mail], *not* to the address of the newsgroup moderator.

If you want verification of arrival, say so 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, source
that doesn't meet the guidelines 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 and my current work load.

-------------------
Subject: Guidelines

To make life easier for both myself and the users of the comp.sources.x
newsgroup, I request that all submissions follow the following guidelines.

Initial Submissions:
    1.  Try to use #include <X11/Xos.h> instead of things like
        types.h, strings.h and time.h
    2.  Please use -display displayname and -geometry geomspec
        instead of the old style.
    3.  Source filenames need to be 12 or fewer characters in length.
    4.  Include an Imakefile.  For more information on Imakefile's,
        read imake.man in util/imake on the X11 Release 4 distribution.
    5.  A Makefile is required.
    6.  A manual page is required.
    7.  A README file is required. This should contain a brief
        description of what the posting is and any special
        considerations in building it. The README should
        also contain a list of authors and the distribution
        and copying policy.
    8.  Postings should be in shar format of <= 75K. If it is necessary to
        split the posting into multiple parts, each shar file should be <= 75K.
    9.  Include a patchlevel.h -- This file is used to keep track
        of how many official patches have been applied.
    10. If fonts are submitted, please assure they are in bdf format.
    11. Any additional documentation (past the required man page)
        should be in PostScript format or some nroff/troff format so
    people can print it out nicely.

Updates, patches, etc.:
    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.
    2.  A patch to patchlevel.h should be done to reflect that the
        patch has been applied.  You are -advised- to include a Prereq:
    line in your patch for this file so that if patchlevel.h fails
    to patch correctly (the user is out of sync), the rest of the
    patches will not be applied.
    3.  Include information about which previously posted issues
        the patch pertains to if they were initially posted to c.s.x.
    This information will be reflected in the Patch-To: header
    when your article is posted.

    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.  Patches can be made with diff -c on 4.XBSD 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.

---------------------------------------
Subject: Editorial comments

  Altho I don't make it a rule, postings which require uuencoded files
  be included are accepted, but I much prefer btoa format.  In fact,
  source code submissions (especially large ones) are more easily
  transferred in mail and more easily stored for me if you use tarmail
  rather than shar.  But this in in my own opinion and I am not making
  any requirements that people use tarmail/btoa at all.

  Why btoa instead of uuencode? First and foremost, uuencode doesn't travel
  well over certain mail transport agents because it uses a "space" as a
  possible conversion character.  There are some MTAs that remove trailing
  spaces from the ends of lines and it would result in a file that you could
  not "decode".  Secondly, the amount of ascii characters actually
  generated by "btoa" is far fewer than uuencode, saving on net traffic.
  Finally, it's just so much easier to deal with -- you don't
  have to worry about setuid, creating files automatically, chmod 666, and
  you can use btoa in a pipe.

    "Top 10 pet peeves of the comp.sources.x moderator."

10.  Submissions that do not contain a README, Imakefile or patchlevel.h.
9.   Submissions that do not contain a man page.
8.   People who ask me if there are any postscript previewers available.
7.   People who send me sources using uuencode (use "shar" files < 75K each).
6.   Programs that don't compile right the first time.
5.   That guy who sends me those digitized frames from the Rob Lowe video.
4.   Shell scripts that post the wrong subject line.
3.   Patches that don't apply correctly.
2.   No, I don't know when R4 is going to be released.
    And the #1 pet peeve by the comp.sources.x moderator...
1.   Requests for previous postings to be resent to them.

dan
----------------------------------------------------
O'Reilly && Associates   [e-mail] / [e-mail]
Opinions expressed reflect those of the author only.