Import of cvs-1.9.9-970515 onto vendor branch.

Obtained from: cyclic.com

1 files changed, 97 insertions, 7 deletions

diff --git a/contrib/cvs/HACKING b/contrib/cvs/HACKING
index ac4cdd1..89f7399 100644
--- a/contrib/cvs/HACKING
+++ b/contrib/cvs/HACKING
@@ -43,11 +43,17 @@ the person checking in such a patch should reindent it.
 
 * Portability
 
-If it is in ANSI C and it is in SunOS4 (using /bin/cc), generally it
-is OK to use it without ifdefs (for example, assert() and void * as
-long as you add more casts to and from void * than ANSI requires.  But
-not function prototypes).  Such constructs are generally portable
-enough, including to NT, OS/2, VMS, etc.
+The general rule for portability is that it is only worth including
+portability cruft for systems on which people are actually testing and
+using new CVS releases.  Without testing, CVS will fail to be portable
+for any number of unanticipated reasons.
+
+The current consequence of that general rule seems to be that if it
+is in ANSI C and it is in SunOS4 (using /bin/cc), generally it is OK
+to use it without ifdefs (for example, assert() and void * as long as
+you add more casts to and from void * than ANSI requires.  But not
+function prototypes).  Such constructs are generally portable enough,
+including to NT, OS/2, VMS, etc.
 
 * Run-time behaviors
 
@@ -58,6 +64,22 @@ but we want to fix that code.  Of course, bad input data, a corrupt
 repository, bad options, etc., should always print a real error
 message instead.
 
+We realize that CVS contains many arbitrary limits (such as PATH_MAX).
+Do not do this in new code; we are trying to *fix* those arbitrary
+limits.  In particular, it should be possible to pass very long
+arguments (e.g. from a WWW cgi script) to CVS without having it
+overrun any buffers (which might create a security hole in the WWW
+example).
+
+Although this is a long-term goal, it also would be nice to move CVS
+in the direction of reentrancy.  This reduces the size of the data
+segment and will allow a multi-threaded server if that is desirable.
+It is also useful to write the code so that it can be easily be made
+reentrant later.  For example, if you need to pass data from a
+Parse_Info caller to its callproc, you need a static variable.  But
+use a single pointer so that when Parse_Info is fixed to pass along a
+void * argument, then the code can easily use that argument.
+
 * Coding standards in general
 
 Generally speaking the GNU coding standards are mostly used by CVS
@@ -65,7 +87,44 @@ Generally speaking the GNU coding standards are mostly used by CVS
 and perhaps an exception or two we haven't mentioned).  This is the
 file standards.text at the GNU FTP sites.
 
-* Submitting patches
+Filenames for .c and .h files may contain _ but should not contain -
+(the latter causes Visual C++ 2.1 to create makefiles which Visual C++
+4.0 cannot use).
+
+* Submitting patches (strategy)
+
+Only some kinds of changes are suitable for inclusion in the
+"official" CVS.  Bugfixes, where CVS's behavior contradicts the
+documentation and/or expectations that everyone agrees on, should be
+OK (strategically).  For features, the desirable attributes are that
+the need is clear and that they fit nicely into the architecture of
+CVS.
+
+However, if there is reason to think that a change would significantly
+inconvenience any significant body of CVS users, or would be
+controversial for other reasons, then the design should be re-thought.
+Go back to the requirements (writing documentation might help, if you
+write the documentation to explain why one would use the feature not
+just what the feature does).  Think about whether there is a behavior
+which works in both your situation and the other situations.  Make a
+list of the issues (for example, submit a comment or documentation
+change).  Ask your coworkers, a newsgroup, or a mailing list, and see
+what other people think.  Distribute some experimental patches outside
+the "official" CVS and see what people think.  By this process, the
+intention is that once-controversial changes can be refined to the
+point where they are relatively uncontroversial before they are
+actually checked in to the "official" CVS.  Features like zlib,
+encryption, and others have benefitted from this process in the past
+by being mentioned in the documentation and/or discussed, before an
+implementation was checked in.
+
+If longstanding CVS behavior, that people may be relying on, is
+clearly deficient, it can be changed, but only slowly and carefully.
+For example, the global -q option was introduced in CVS 1.3 but the
+command -q options, which the global -q replaced, were not removed
+until CVS 1.6.
+
+* Submitting patches (tactics)
 
 Please include a ChangeLog entry (see the GNU coding standards for
 information on writing one) with patches.  Include a description of
@@ -74,7 +133,11 @@ the code are appropriate for this, but not always)--patches should not
 be checked in unless there is some reason for them, and the
 description may be helpful if there is a better way to solve the
 problem.  In addition to the ChangeLog entry, there should be a change
-to the NEWS file in the case of a new feature.
+to the NEWS file and cvs.texinfo, if the change is a user-visible
+change worth mentioning.
+
+It is nice to have a test case (see TESTS), especially for fixes which
+involve subtle behaviors or twisted sections of the code.
 
 If you solve several unrelated problems, submit a separate
 patch for each one.  Patches should be tested before submission.  Use
@@ -100,3 +163,30 @@ even hinted at, really) until the feature freeze which is
 approximately 2 weeks before the final release (at this time test
 releases start appearing and are announced on info-cvs).  This is
 intentional, to avoid a last minute rush to get new features in.
+
+* Mailing lists
+
+Anyone can add themselves to the following mailing lists:
+
+    devel-cvs.  Unless you are accepted as a CVS developer as
+      described in the DEVEL-CVS file, you will only be able to
+      read this list, not send to it.  The charter of the list is
+      also in DEVEL-CVS.
+    commit-cvs.  The only messages sent to this list are sent
+      automatically, via the CVS `loginfo' mechanism, when someone
+      checks something in to the master CVS repository.
+    test-results.  The only messages sent to this list are sent
+      automatically, daily, by a script which runs "make check"
+      and "make remotecheck" on the master CVS sources.
+To subscribe to devel-cvs, commit-cvs, or test-results, send
+a message to "majordomo@cyclic.com" whose body consists of
+"subscribe <list>", where <list> is devel-cvs, commit-cvs or
+test-results.
+
+One other list related to CVS development is bug-cvs.  This is the
+list which users are requested to send bug reports to.  Anyone can
+subscribe; to do so send mail to bug-cvs-request@prep.ai.mit.edu.
+
+Other CVS discussions take place on the info-cvs mailing list
+(send mail to info-cvs-request@prep.ai.mit.edu to subscribe) or on
+the newsgroup comp.software.config-mgmt.