From: utzoo!watmath!decvax!ittvax!swatt
Newsgroups: net.news.b
Title: Suggested protocol for forwarding news fixes/improvements
Article-I.D.: ittvax.373
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.."
where is your UUCP system name, and
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
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,
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 is not specified, assume .
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 <$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
==================================================================