From: utzoo!decvax!harpo!npois!cbosgd!mark
Newsgroups: net.news.b
Title: Re: Suggested protocol for forwarding news fixes/improvements
Article-I.D.: cbosgd.2425
Posted: Wed Jun 30 23:23:17 1982
Received: Thu Jul  1 06:38:45 1982
References: ittvax.373

I think Alan has made some excellent suggestions.  I agree with all
of them.  I'd also like to make a couple of comments.

There is no question that the current system of an update coming
out randomly is a pain for everyone who maintains news on his
system.  A better way needs to be worked out.  The current flurry
of updates (2.7, 2.8, 2.9) really shows up the problem, even though
2.7 was the release and 2.[89] were fixes to serious bugs in 2.7.

Probably a schedule for updates needs to be announced, in some way.
An update can be planned, and it should be announced roughly a month
or more in advance, so sites can plan to install it.  These updates
probably should come no more frequently than every 2 months.

There should be a group of "test sites" to which new releases are
sent for testing before they go out to everybody.  Hopefully they
would represent all the operating systems and hardware.  The sites that
have been doing most of the testing all seem to be vaxen running 4.1BSD.
We also need test sites which (1) run USG UNIX, (2) are on the ARPANET,
(3) run vanilla V7, (4) are pdp-11's, (5) are other things besides vaxen.

Also, it is becoming clear that there are MANY sites running very old
versions of news.  These tend to cluster in certain parts of the network,
for example, UCSD, BTL IH, Tektronix, and the NC Triangle were blatantly
missing from the responses to my recent attempt to build a map.  (So
is Silicon Valley, because of reply problems due to arpanet addresses.
Some of the others may have been reply problems too, but I can't tell.)
These sites probably either (1) don't have the time/energy to update
to a newer news, or (2) have significant local mods that they don't
have the manpower to re-integrate into each release.

We need to do something to make it easier for these sites to upgrade.
In a network environment, you can't take the whole network down at
once to change protocols, even if you control every site (which nobody
does).  Making a change to a new protocol is very hard, so changes
have to be done in an upward compatible manner.  If sites run 2 year
old versions of news, it's hard to phase out some code that's in there
for upward compatibility.  With this in mind, I'd like to encourage
sites with local mods to forward them to the maintainers.  If the job
of integrating them into the master copy is made easy, chances are
very good that they will be bought back.  (If the change is not an
improvement for everybody, it can probably be ifdeffed.)

We also might want to think about using netnews to automatically
update and install itself.  Obviously this not a well thought out
issue and has lots of problems, but by posting to certain newsgroups
(net.adm.all, presumably) it would be possible to have software
(such as, but not restricted to, netnews) automatically updated.
This service could be used for other things - the obvious immediate
application is to keep the network map up to date.  Also, a shell
script or program to take an update and apply it (doing the local
configuration, maybe using diff3, recompiling, and installing)
would be a useful addition to news.  Tools for the maintainer
need some attention.

Finally, there is the A vs B vs notesfiles issue.  I think most of
the people who have seen notesfiles think it has a wonderful user
interface.  What is not year clear is what happens with notesfiles
in a big network.  I propose a large scale test of notesfiles by
having several volunteer sites form into a subnet of USENET, using
notesfiles, with at least 2 gateways to the B news part of the net.

Remember, there is nobody being paid ONE RED CENT to support USENET.
Nobody at Duke, UNC, Berkeley, Bell Labs, or Illinois is being
pressured by anyone to drop everything else and support news.
All these people have some other thing they are (supposed to be)
spending their time on, and support their software only as a
labor of love.  Much of what gets done is done because ONE OF YOU
does it and sends the improvement to the central source.  So next
time you want to complain that you don't like feature X, or ran
across bug Y, or want whistle Z, instead of flaming about it, get
off your duff and fix it!  This is a network of, by, and for the USERS.
That's you!

	Mark