? GCS.patch
Index: standards.texi
===================================================================
RCS file: /sources/gnustandards/gnustandards/standards.texi,v
retrieving revision 1.242
diff -U 3 -r1.242 standards.texi
--- standards.texi	23 Apr 2015 15:48:55 -0000	1.242
+++ standards.texi	8 Jul 2015 01:01:56 -0000
@@ -3,7 +3,7 @@
 @setfilename standards.info
 @settitle GNU Coding Standards
 @c This date is automagically updated when you save this file:
address@hidden lastupdate April 23, 2015
address@hidden lastupdate July 8, 2015
 @c %**end of header
 
 @dircategory GNU organization
@@ -4082,6 +4082,11 @@
 major version and a minor.  We have no objection to using more than
 two numbers, but it is very unlikely that you really need them.
 
+Making a release means providing a package for distribution.  If you
+use a version control system, you might also want to tag the point in
+the history where the release was made.  But this in itself is not
+sufficient.
+
 Package the distribution of @code{Foo version 69.96} up in a gzipped tar
 file with the name @file{foo-69.96.tar.gz}.  It should unpack into a
 subdirectory named @file{foo-69.96}.
@@ -4128,6 +4133,11 @@
 install whichever versions of whichever packages they like.  Do not
 induce new dependencies on other software lightly.
 
+Don't allow any part of the build or configure process to open a 
+network connection in order to download files remotely (or for any other reason).
+The distribution should successfully build on a machine disconnected 
+from the internet.
+
 Non-source files that might actually be modified by building and
 installing the program should @strong{never} be included in the
 distribution.  So if you do distribute non-source files, always make