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 ==================================================================