To make a patch

1.  get the sources from /source/...

attach source
cd /source
look thefile FILES.look
and go on down...

2.  make the fix

(I'll leave this to your imagination)

3.  test it--on DEC, RS6000, SUN

(I'll leave this to your imagination, too)

4.  make up the package.

	a.  summary of the problem and your fix
	b.  a patch file
	c.  other test materials, etc.

(in case you're not sure what the best way to make a patch file is,
here are the directions!)

When submitting patches, create them with something like

	diff -c oldfile newfile > patchfile

and then insert patchfile directly into your mail buffer.

This creates a diff with three important properties:

	First, the -c gets you a context diff; it shows you the
	code around the actual changes so that just looking at them,
	it's easier to get an idea how the patch actually works.
	Also, this makes the patch more robust - patch(1) will often
	be able to apply the patch even if the source has changed
	since the patch was generated, since it can now do searches
	for the unchanged context if the line numbers no longer match.

	Second, giving the arguments to diff as "oldfile" followed by
	"newfile" generates output for patch to modify oldfile to
	turn it into newfile. In the other order, diff generates output
	to turn newfile into oldfile. "<" means take this line out;
	">" means add this line. Also, using this convention makes
	patches much more readable - you never have to guess which
	way the diff was done.

	Third, the patch in patchfile has preserved white-space
	correctly. Don't cut & paste the output from patch from an
	xterm. White-space in patches is important, and cutting out of
	an xterm does not preserve the tabs - it converts them into
	spaces. Attempting to apply such a patch to the original file
	will fail.

5.  last, but not least, send your patch to rel-eng.