diff options
author | peter <peter@FreeBSD.org> | 1997-05-15 22:46:24 +0000 |
---|---|---|
committer | peter <peter@FreeBSD.org> | 1997-05-15 22:46:24 +0000 |
commit | 4f40fe8334ad5f056e1d9105f23fe7ac859c39ba (patch) | |
tree | 3b2f0092fa216d9f61059ba94b7f10b5bacf9496 /contrib/cvs/HACKING | |
parent | 8982e501c77217c860f79bba431f46a62b607a21 (diff) | |
download | FreeBSD-src-4f40fe8334ad5f056e1d9105f23fe7ac859c39ba.zip FreeBSD-src-4f40fe8334ad5f056e1d9105f23fe7ac859c39ba.tar.gz |
Import of cvs-1.9.9-970515 onto vendor branch.
Obtained from: cyclic.com
Diffstat (limited to 'contrib/cvs/HACKING')
-rw-r--r-- | contrib/cvs/HACKING | 104 |
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. |