comp.sources.reviewed -> comp.sources.posix (+ c.s.u controversy)

Warren Tucker wht
Sun Mar 3 05:19:00 AEST 1991


In article <1991Mar1.163137.293 at twinsun.com> eggert at twinsun.com (Paul Eggert) writes:
>This suggests that for sanity's sake, the newsgroup will stick to Posix
>(or at least Posix-like) applications.  It also suggests that competent
>reviewers will check for Posix conformance.  This will indeed be a
>service to the computing community.

My 2e-02 cents worth on c.s.u/c.s.m and the article subject.

C.S.M/C.S.U/C.S.R BABBLE, ER, DISCUSSION
----------------------------------------
I love how somebody recently said "[I enter into this discussion
carefully]." I appreciate the mammoth job of moderating c.s.u and
understand how long periods of time can pass with no activity.
I suspect Mr.  $alz of having to commit paid commerce so he has
shekels for gas to and from work.  This obviously takes him away
from net.demands.  I pass no judgment upon him and have no
opinion on "what we should do about c.s.u."

c.s.m is a very good alternative for distribution.  Brandon was
and Kent is very helpful in getting releases organized and sane.
Both have saved me from extremely red faces (not that it hasn't
been Pink a few times anyway :-)).  But there is where it stops.
This has been fine for me.

Between (c.s.u) heavy testing with delays and (c.s.m)
administrative help only with blindingly fast transmission some
perceive a void. comp.sources.reviewed seems to me a viable
middle ground.

Let me use my ECU as a straw dog for comparing the various groups.

I sent a thoroughly nauseating posting, 2.70, my first large one, through
alt.sources and got my first healthy taste of flames and good suggestions.
Only a few people came forward, but enough to get OS version differences
and other issues settled.  Alt.sources gave me the chance for a smoke test
and resulted in a sounder offering.

I submitted ECU 2.74 to comp.source.unix a couple of years ago. It
was delayed (I might offer that it was about the time the Smithsonian
astronomical package and other large stuff was going through).  I
  o got tired of waiting
  o upraded the program to 2.8
during that time.  While nothing came out on the net, the ultimate
offering did benefit from the delay.  For me, at least, I often find
that no matter how hard I work on a business letter, I usually find
improvements I could have soon after I mail it.  So, c.s.u was a plus.

I submitted 2.8 to the net via c.s.m.  It was then that my great
Q.A. friend, Tom Betz (tbetz at upaya) came forward with all manner of
bugs, suggestions, and best of all, encouragement.  He put the program
through more hoops and advanced use than I very likely ever will.

When it came time for ECU 3, I had added new features that I and Tom
could test, but also "experimental" features neither of us could test well or
at all:  various terminals for non-ANSI support, the ISC port attempt
and the GCC environment.  As a result, after 6 patches future downloaders
will have to know about and hunt for (thanks for the patchlog, Kent!),
ECU 3 is stable.

Had c.s.reviewed been around, a ready mechanism would have been
in place that perhaps would have eliminated *all* those patches.
While the net would have had to wait for ECU 3 a while longer
(breathlessly, no doubt :-)), many would also have been spared
seeing a rash of patches, including one that Broke the published version
and had to have a patch to a patch.

Now, you may say, "Warren, c.s.r may have kept you from making several
knee jerk postings, but some of us are more mature and careful in
our submissions."  I agree in part. There are many wonderful offerings
in all the groups which have never required a single patch. I wish
I were that good ;->, but I am not alone in trying to code for
environments I don't have.  Patches are inevitable in those cases.

C.S.M/C.S.U/C.S.R BOTTOM LINE
-----------------------------
c.s.r would 

 o provide a more reliable and organized way to find motivated
   tester-critics 
 o increase the number of cases and environments for testing
 o improve the end product and reduce patch frequency
 o more than compensate for delays in net.delivery.
 o should be a comp.sources."new-and-augmenting" not a comp.sources.
   "all-is-made-new" or comp.sources."death-to-$alz".

C.S.POSIX COMMENT
-----------------
UNIX C and shell scripts, VMS C and shell scripts, Perl scripts,
awk scripts, MSDOS C, assembler and Pascal, X11 bitmaps, FORTRAN,
Amiga C, standalone man pages and a host of other kinds of
"source" have shown up there.

 o Many/most of these have no POSIX applicability; let's not
   exclude 90% of reality from the comp.sources."new-thang"
 o POSIX is better defined than the ANSI C pseudo-standard debacle
   and both have laudable goals; yet, both doomed us to not one
   extra environment to support, but a rash of mutltivariate
   interpretations of what different providers thought these
   standards meant; just say "no, FALSE, 0, EOF, NIL, NULL, NUL,
   "(null)", NAK, NAK, NAK, CAN, EOT, ...-.-" (but I diverse).
------------------------------------------------------------------------
Warren Tucker, TuckerWare     emory!n4hgf!wht or wht at n4hgf.Mt-Park.GA.US
"An ANSI C elephant: just like the real one, but the position, shape and
length of the trunk and tail are left to the vendor's discretion." -- me

-- 
----------------------------------------------------------------------------
Warren Tucker, Tridom Corporation, gatech!n4hgf!wht, wht at n4hgf.Mt-Park.GA.US
When bad men combine,  the good must associate;  else they will  fall one by 
one, an unpitied sacrifice in a contemptible struggle. -Edmund Burke



More information about the Alt.sources.d mailing list