Message-ID: <bnews.ittvax.373>
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

  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
  : '/*********************************************************************
  	Create executable script to update sources.

  	Alan S. Watt


  		upd_diff old_source new_source [ destination ]

  		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.

  		06/21/82	original version



  	upd_diff old_version new_version location


  	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.

  : 'If your diff has -c ("context") option'

  old="$1" ; new="$2"
  case $# in
  3)	loc="$3" ;;
  2)	loc="$2" ;;
  *)	echo "usage: $VERBOSE" 1>&2 ; exit 1 ;;

  cat <<!EOF
  echo -n "$old: "
  sum $old >$SUMF
  if cmp - $SUMF <<$DELIMIT
  `sum $old`
  	echo "OK -- applying edit commands"
  	cp $old $TEMPF ; chmod +w $TEMPF
  	ed - $TEMPF <<\\$DELIMIT
  `diff -e $old $new`
  	rm -f $loc
  	cp $TEMPF $loc ; chmod a-w $loc
  	echo "Old source file not same version;" \\
  		"use diff listings by hand" <<$DELIMIT
  `diff $CONTXTOPT $old $new`
  rm -f $TEMPF $SUMF

Message-ID: <bnews.cbosgd.2425>
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!


			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.