🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sources.d
Article #1164

Re: How to make a faster comp.sources.unix

#1164
From: Dan Bernstein
Date: Sun, 02 Dec 1990 22:11
87 lines
4478 bytes
In article <1990Dec2.013833.13194@usenet.ins.cwru.edu> edguer@charlie.CES.CWRU.Edu (Aydin Edguer) writes:
> Okay.  Rich $alz usually requires the following to publish a source.
> 	1) a makefile
> 	2) documentation
> 	3) a manual page
> 	4) it works (at least compiles) on the moderators machine
> What are you now talking about adding?

This is orthogonal to the requirements. It's just something to ease the
burden on Rich of portability testing.

> I assume you want to test the program on the different variants of UNIX.
> What is the "minimum" subset?  BSD4.2, BSD4.3, BSD4.3Tahoe, BSD4.3Reno, SVR2,
> SVR3, XENIX, XENIX 286, SVR4, ULTRIX, SunOS, HP-UX, UNICOS, OSF/1, BSD2.10?

Whatever testers provide is good.

> So, lets say that the program does not work under System V.  Does the source
> not get published?  Does the source get published but with a warning?

What currently happens is that most sources get published with a list of
machines they've been tested on. When a new version is sent out, the
author adds to the list anything people tell him about.

Now the extra testing would just be a small-scale rendition of what
happens when the software is posted. So if the author hears ``it doesn't
work under System V,'' he might say ``I knew that, README says it's only
for BSD,'' or ``Oh, whoops, let me try to fix that before we go ahead,''
or ``I didn't realize it wasn't portable---please add it to the bottom
of README.'' This is exactly what happens for user comments now.

> Let's say that the moderators

There's only one moderator, namely Rich. As a tester I'd do exactly what
I do when I see a package posted: bring it up on the most ``standard''
machine I can find (a Sun 4 running SunOS 4.0.3), and see what I think.
If it shows any promise I'll try it on other machines. This is a lot
less work than what goes into moderation---checking for sanity, making
improvements, dealing with a huge number of mail messages, and posting
software that people can trust.

> find some compatibility problems.  Do they
> send the changes back to the author?  Do they make up patches and send them
> along with the source?

As above, information goes back to the author. Sure, patches help.

> What if an author decides that they do not want to support the software on
> systems they do not have access to?  Do the moderators release "unofficial"
> patches?

If the testers want to post unofficial information about a package, they
can (though they should wait for the final version in case there are
more changes). As always, the author makes the final decision about what
his package should contain.

> What if one of the moderators does not finish testing within the one or two
> week limit for processing?  Does the whole posting get held up?  

A tester who can't get back to Rich in a reasonable time won't get any
more software.

> Does
> the posting get made but with a message saying it is untested under XYZNIX?

It's usually stated positively: ``This package has been tested under
these systems...'' Someone with XYZNIX will, of course, be more
confident in a package that has already been tested under XYZNIX than
with one that's only been tested with the older versions, XNIX and
XYNIX, or with competitor ZYXNIX.

> Should list of moderators be limited to people with Internet connections?

Why?

> Do moderators have to test out future patches in addition to the sources?

Do you have to install every future version of a program you use? It's
less work than the first time, but except for major programs like news
where you have to interoperate with the rest of the world, there's no
need. And lots of sites never seem to upgrade news...

Before I send code to Rich or anywhere else, I try it out on a small
scale. People bang on it for a while, and I use their comments to
improve it. This would just be a slightly bigger next step.

---Dan
Technical Details
Message-ID: <11343:Dec222:11:4390@kramden.acf.nyu.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
References: <10770:Nov3009:18:4790@kramden.acf.nyu.edu> <1990Dec1.214721.15514@NCoast.ORG> <1990Dec2.013833.13194@usenet.ins.cwru.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.sources.d
Subject: Re: How to make a faster comp.sources.unix
Message-ID: <11343:Dec222:11:4390@kramden.acf.nyu.edu>
Date: 2 Dec 90 22:11:43 GMT
References: <10770:Nov3009:18:4790@kramden.acf.nyu.edu> <1990Dec1.214721.15514@NCoast.ORG> <1990Dec2.013833.13194@usenet.ins.cwru.edu>
Organization: IR
Lines: 87