Source Code 1994 March/Source_Code_CD-ROM_Walnut_Creek_March_1994.iso/compsrcs/unix/volume26/v26inf4

Text File | 1992-06-30 | 5.3 KB | 109 lines

Subject:  v26INF4:  Why moderating comp.sources.unix is difficult and slow
Newsgroups: comp.sources.unix
Approved: [e-mail]

Submitted-by: [e-mail] (Paul Vixie)
Posting-number: Volume 26, Info 4
Archive-name: v26INF4

We have 131 messages in our work queue, of which a few are multi-part
submissions, so there are probably only about 100 submissions in all.
These submissions date back to February of this year (1992).  Many of
you have asked directly the obvious question: "why have you not posted
my sources yet?".  Even more of you have mentioned in passing that you
submitted something to comp.sources.unix "a few months ago" but that
the moderators "appear to be busy".  Wonderful euphemism, that.

Since the year is half over, we figured we'd better take stock of the
situation, see what's wrong, and unwedge things again.  The problem is
not that the moderators are busy.  While it's true that the moderators
are busy, the problem lies elsewhere.  What's wrong is that the moder-
ators spend way too much time wringing their hands over "almost good
enough" submissions, and wanting to be fair, we prefer to send stuff
out in more or less the order it came in.

Which is not to say that everything submitted since February has been
waiting for some problem to be resolved with the earliest item in the
queue.  Actually there are about 15 things early on in the queue that
were "not quite right", and that was about as far ahead/behind as we
wanted to get.  Unfortunately, it appears that we're going nowhere fast.
So the rules are about to change.

PROCESS

1. We've been fixing things up.  No more.  If your package comes to us
without a proper Makefile (see below), without a README, or without a
man page for each installed command (or library routine, if it's a code
library), we're going to bounce it.  We might offer suggestions on how
to improve it, but we are not going to do the work ourselves and we are
not going to hang onto a copy so that you can send us updates.

2. Anything that we get that wasn't packaged with Rich Salz' "cshar2",
we will repackage.  We don't think it's reasonable to require every
author to have a copy of "cshar2", but we definitely want all the shar
files in this group to have the same format.  This raises some important
points:
    2a. no file can be longer than 90K
    2b. no file can have non-printable-ASCII characters in it

If your package just has to break one of those rules, then we will
consider using your "shar" files rather than repackaging them ourselves.
If your "shar" files require oddball commands which aren't present on
most Usenet hosts, and your submission breaks one of the above rules,
we'll refuse to publish your package.  We'll be polite, but we'll refuse.

3. We will be relatively happy to retrieve things via anonymous FTP,
unpack the .tar.Z file, make "cshar2" files out of it, and post it.  In
fact we'd prefer to operate this way.

4. Our goal is for this group to be fairly fluid.  Folks will post goodies,
and we'll either bounce them or post them within a week or so.  The only
way we can make this work is to stop fiddling around with submissions and
operate on a "hair trigger" for bouncing things we don't think are good
enough.  Hopefully the fluidity will encourage more high-quality submissions.

CONTENT

The goal of this group is to get a lot of free software to a lot of users
without a lot of work on the part of the authors, the moderators, or the
users.  But if work is needed it will have to be done by the authors.  We
have identified a quality baseline that makes software immediately usable
by the largest possible number of Usenet readers.  If a submission doesn't
measure up, we'll tell you why and it's up to you to resubmit a complete
new version with changes, or bail out and post it to alt.sources.

Everything we post here MUST have a Makefile -- even library packages.  The
Makefile SHOULD be V7-compatible, meaning no "include" files or VPATH's or
any of that goop -- but we won't make a stink about it.  Your Makefile MUST
have at least these targets:

    all (must be first and therefore default) -- this must build
        all the files that will be installed.

    install -- this must nondestructively (cp, not mv; or install -c)
        install all the things built by "all", plus all the man
        pages or library support files that are probably included
        in installable format (that is, not built by "make all").

    install.man, et al -- don't do it.  use "make install".

    clean -- this must delete all the files built by "all" and "install".
        "clean" can also wipe out "core", "a.out", editor backups,
        and other junk that may or may not exist.

Every submission needs a README file which we will either copy completely or
excerpt for the top of the first article of your submission.

Every command or library entry point installed by "make install" must have
a man page in "nroff -man" format.  Don't preformat the man pages, either
as submitted or as built by "make all" or "make install".  Anyone on Usenet
can turn an "nroff -man" file into readable documentation, but it's very
difficult to go back the other way.  Note that only the commands that the
end-users will execute need man pages; if you install a shell script called
"console" that depends on a never-to-be-run-directly command called "rtty",
then only "console" needs a man page.

            -Paul Vixie (who wrote this post)
            -Mike Stump (who hasn't seen it yet)
            -Nick Lai (likewise)