Message-ID: <bnews.ittvax.373>
Newsgroups: net.news.b
Path: utzoo!watmath!decvax!ittvax!swatt
X-Path: utzoo!watmath!decvax!ittvax!swatt
From: ittvax!swatt
Date: Thu Jul 1 00:56:10 1982
Subject: Suggested protocol for forwarding news fixes/improvements
Posted: Wed Jun 30 17:47:58 1982
Received: Thu Jul 1 00:56:10 1982
Like a lot of people, I try to maintain the news system in spare
time. I also try to be responsible to the user community by:
performing some rudimentary tests on updates before
installing them.
Verifying new features are adequately described in the
documents and preparing a short blurb on what's new.
Arranging to have printed documents made up if the update
changes established behavior.
I have found the stream of bug reports/improvements/distributed
updates a considerable pain to handle at times. 2.9 is just out
and due to various problems I haven't installed 2.8 yet.
However, I recognize netnews is public software largely written
and maintained on volunteer time, so I'M NOT COMPLAINING. This
is to post some thoughts on how we can all reap more benefits,
suffer fewer frustrations, and do it all in less spare time.
1. Distribution:
News system updates will be distributed from the present source
(ucbvax!ARPAVAX:usenet) at standard intervals. The precise
interval will obviously depend on the time available to assemble
it all. While there are obvious advantages to frequent updates
to keep everyone in sync with bug fixes, I suggest one update
each month is too often; it will more likely lead to inadequate
testing and MORE bugs.
Distribution will be by diff listings against the current
sources. I humbly append my proposed tool for making the editor
scripts that should keep the diff -c fans happy and still allow
most sites to automate the process.
2. Local Modifications and Enhancements
All sites are encouraged to send their bug fixes, enhancements,
etc., to the central maintainer for incorporation into standard
releases. Submissions should use the update script tool included
in the appendix (or a better one; I'm not all that proud).
2.1 Scope and Size of Submission
Each submission should cover only ONE change. That is don't wait
until 5 days before the next standard release date and dump all
your locally made fixes on Matt (or whomever) all at once. If
you find three separate bugs, send three separate reports.
2.2 Content of Submission
All modification submissions should include:
1) A unique identifier. I suggest "UPD.<sysname>.<seqnum>"
where <sysname> is your UUCP system name, and <seqnum>
is a submission sequence number. When standard updates
come out, all submissions included will be referenced by
these identifiers, so local maintainers can easily verify
their changes have been incorporated.
2) A brief (1 or 2 line) description of the change. This
will also be included in the standard distribution.
3) A sample test case to demonstrate the bug (if appropriate
and possible).
4) The actual edit script (or diff listing, or description,
or whatever) to effect the alteration of sources.
5) A sample test case to demonstrate the proper functioning
of the new feature (if appropriate and possible).
6) (I shouldn't have to say this!) No modification and/or
enhancement is complete without a description incorporated
in the documents, helpfiles, etc.
Submissions describing serious bugs may also be posted to the net
for immediate action by local maintainers; they should not
necessarily prompt more frequent official updates. Local
maintainers may incorporate fixes so distributed, treating them
as local additions.
Nothing requires the central maintainer to accept proposed
modifications. The central maintainer will, time permitting,
reply to contributors stating whether their proposed modification
is accptable or not.
3. Local Maintenance
Local maintainers are responsible to keep copies of the "official
current" sources. Local changes are kept in separate copies.
3.1 Making Local Changes
As previously stated, all local changes will be named by a unique
identifier. The complete description of any local news system
will therefore be the last official version on which it was based
and the set of named changes applied locally.
3.2 Applying Official Updates
All official updates are relative to the "official current"
sources. The central maintainer will specify what the current
official version is and how it is determined. The central
maintainer will also distribute a file with each update derived
from running sum(1) on all sources so local maintainers can
verify their system is an exact image of the official current
one. For 2.9 this would look like:
35136 3 defs.h
44045 1 header.h
53005 1 iparams.h
45228 2 params.h
13300 2 rparams.h
<and so on ...>
When the official update comes out, local maintainers will check
the list of modification identifiers with those they have made
locally and if the official set is a superset of their own, they
can simply junk the current local sources, restore the current
official sources and apply the update. If for any reason they
have made local changes not reflected in the official update,
they have some hand editing to do.
4. Netnews Maintenance Governing Board
Notwithstanding anything said here:
1) The central maintainer can resign anytime.
2) Local maintainers can resign anytime.
3) Local users can get bored and unsubscribe to everything
anytime.
4) We can discuss this to death over the net.
5) We can debate whether the proper place to discuss
this to death is the USENIX conference.
OR we can do something constructive about it.
It's great to get the kind of service USENET provides without
having to write it all yourself, but the only way it can continue
to work is if everyone has a little consideration for other
people trying to keep their local systems running. Remember also
since it's free, nobody can make demands on the time of others to
fix or improve it -- be nice and try to help them.
- Alan S. Watt
==================================================================
APPENDIX - Automatic Update Script Generator
This shell script is right-shifted by two spaces.
==================================================================
#! /bin/sh
: '/*********************************************************************
upd_diff
Create executable script to update sources.
Alan S. Watt
Sccsid=@W@
usage:
upd_diff old_source new_source [ destination ]
arguments:
old_source: Original source file to be updated
new_source: New source file created by updates
destination: where to put final copy. If not specified,
<new_source> is assumed.
history:
06/21/82 original version
*********************************************************************/'
VERBOSE='
Usage:
upd_diff old_version new_version location
or
upd_diff old_version new_version location | sh
If <location> is not specified, assume <new_version>.
The output is a command stream for sh(1) to create the new
version in the specified location. The second usage will
take the output and pipe it into a shell for execution.
First, sum(1) is used to verify the source is the same as
that used to produce the diff -e. If the match succeeds,
commands will be executed to perform the edit. Otherwise,
a warning message will be printed. In either case, an
in-line human-readable diff listing will be generated for
hand editing.
'
TEMPF='/tmp/upd.$$.tmp'
SUMF='/tmp/upd.$$.sum'
SAVE="/usr/old"
DELIMIT=!EOF.$$
: 'If your diff has -c ("context") option'
CONTXTOPT="-c"
old="$1" ; new="$2"
case $# in
3) loc="$3" ;;
2) loc="$2" ;;
*) echo "usage: $VERBOSE" 1>&2 ; exit 1 ;;
esac
cat <<!EOF
echo -n "$old: "
sum $old >$SUMF
if cmp - $SUMF <<$DELIMIT
`sum $old`
$DELIMIT
then
echo "OK -- applying edit commands"
cp $old $TEMPF ; chmod +w $TEMPF
ed - $TEMPF <<\\$DELIMIT
`diff -e $old $new`
w
q
$DELIMIT
rm -f $loc
cp $TEMPF $loc ; chmod a-w $loc
else
echo "Old source file not same version;" \\
"use diff listings by hand" <<$DELIMIT
`diff $CONTXTOPT $old $new`
$DELIMIT
fi
rm -f $TEMPF $SUMF
!EOF
==================================================================
Message-ID: <bnews.cbosgd.2425>
Newsgroups: net.news.b
Path: utzoo!decvax!harpo!npois!cbosgd!mark
X-Path: utzoo!decvax!harpo!npois!cbosgd!mark
From: cbosgd!mark
Date: Thu Jul 1 06:38:45 1982
Subject: Re: Suggested protocol for forwarding news fixes/improvements
References: <bnews.ittvax.373>
Posted: Wed Jun 30 23:23:17 1982
Received: Thu Jul 1 06:38:45 1982
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
|