[31680] trunk/base/HACKING

jberry at macports.org jberry at macports.org
Sun Dec 2 16:24:33 PST 2007


Revision: 31680
          http://trac.macosforge.org/projects/macports/changeset/31680
Author:   jberry at macports.org
Date:     2007-12-02 16:24:31 -0800 (Sun, 02 Dec 2007)

Log Message:
-----------
Hard wrap and detab HACKING file. Whitespcae changes only.

Modified Paths:
--------------
    trunk/base/HACKING

Modified: trunk/base/HACKING
===================================================================
--- trunk/base/HACKING	2007-12-03 00:17:18 UTC (rev 31679)
+++ trunk/base/HACKING	2007-12-03 00:24:31 UTC (rev 31680)
@@ -1,35 +1,72 @@
 # Project naming and copyright attribution:
 
-* "The MacPorts Project" is the string that shall be used whereever there's a need to reference our project name, such as in copyright notices.
-* A developer or contributor is advised to attribute himself a copyright notice if he/she is contributing a full new source file or a full new feature
-  to an already existing source file in the "base" component of our repository.
-* An exception to this rule is our Portfiles, since they are partly meant for human eyes consumption and the boilerplate header comments should be kept
-  down to a minimum
-* A copyright notice attributed to our group name, "The MacPorts Project", should also be added to these source files (if not already there) if they're
-  being uploaded to the "base" component of our repository, since as such they are being contributed to the project.
+ *  "The MacPorts Project" is the string that shall be used whereever
+    there's a need to reference our project name, such as in copyright
+    notices.
 
+ *  A developer or contributor is advised to attribute himself a copyright
+    notice if he/she is contributing a full new source file or a full
+    new feature to an already existing source file in the "base"
+    component of our repository.
 
+ *  An exception to this rule is our Portfiles, since they are partly
+    meant for human eyes consumption and the boilerplate header comments
+    should be kept down to a minimum
+
+ *  A copyright notice attributed to our group name, "The MacPorts
+    Project", should also be added to these source files (if not already
+    there) if they're being uploaded to the "base" component of our
+    repository, since as such they are being contributed to the project.
+
+
 # Commits to the "base" component of the repository:
 
-* Commits with user-visible affect made to the "base" component of the repository should be accompanied by a corresponding entry in the base/ChanegeLog file,
-  with references to pertitent Trac ticket numbers and svn commit revisions where appropriate.
-* Such entries to the ChangeLog need not be full duplications of their related commit logs if the latter are thorough explanations of what's involved in the commit.
-  In such cases it's perfectly acceptable to enter just a summary of the commit and point the reader to further information through the related svn revision
-  and Trac ticket number (if applicable).
-* Related commits to "base" should be grouped in a single ChangeLog entry.
-* Commits to "base" need not update the base/NEWS file, as such will be constructed with the relevant information at MacPorts release time by the release engineers.
+ *  Commits with user-visible affect made to the "base" component of the
+    repository should be accompanied by a corresponding entry in the
+    base/ChanegeLog file, with references to pertitent Trac ticket
+    numbers and svn commit revisions where appropriate.
 
+ *  Such entries to the ChangeLog need not be full duplications of their
+    related commit logs if the latter are thorough explanations of
+    what's involved in the commit. In such cases it's perfectly
+    acceptable to enter just a summary of the commit and point the
+    reader to further information through the related svn revision and
+    Trac ticket number (if applicable).
 
+ *  Related commits to "base" should be grouped in a single ChangeLog
+    entry.
+
+ *  Commits to "base" need not update the base/NEWS file, as such will be
+    constructed with the relevant information at MacPorts release time
+    by the release engineers.
+
+
 # Whitespace rules as discussed on the development list (macports-dev):
 
-* All source code files MUST use soft tabs at a tabstop of 4. No hard tabs are allowed.
-* All source code files SHOULD have the following as the first line of the file:
-    # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4
-  This is a modeline that works for both emacs and vim.
-* Portfiles SHOULD use soft tabs at a tabstop of 4, but implementation of this is left up to the discretion of the maintainer.
-* Portfiles SHOULD use the given modeline
-* Makefiles MUST use tabs as it is required by the syntax. Makefiles SHOULD use a tab stop of 8.
-* Makefiles MAY use a modeline. The following works for emacs and vim:
-    # -*- coding: utf-8; mode: Makefile; tab-width: 8; indent-tabs-mode: t -*- vim:fenc=utf-8:filetype=Makefile:noet:sw=8:ts=8
-* All other files (documentation, etc) SHOULD use soft tabs at a tabstop of 4 if the document format allows.
-* All other files (documentation, etc) SHOULD NOT use a modeline as it is probably meant for human consumption.
+ *  All source code files MUST use soft tabs at a tabstop of 4. No hard
+    tabs are allowed.
+
+ *  All source code files SHOULD have the following as the first line of
+    the file:
+        
+        # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4
+        
+    This is a modeline that works for both emacs and vim.
+    
+ *  Portfiles SHOULD use soft tabs at a tabstop of 4, but implementation
+    of this is left up to the discretion of the maintainer.
+
+ *  Portfiles SHOULD use the given modeline
+
+ *  Makefiles MUST use tabs as it is required by the syntax. Makefiles
+    SHOULD use a tab stop of 8.
+
+ *  Makefiles MAY use a modeline. The following works for emacs and vim:
+ 
+        # -*- coding: utf-8; mode: Makefile; tab-width: 8; indent-tabs-mode: t -*- vim:fenc=utf-8:filetype=Makefile:noet:sw=8:ts=8
+
+ *  All other files (documentation, etc) SHOULD use soft tabs at a tabstop
+    of 4 if the document format allows.
+
+ *  All other files (documentation, etc) SHOULD NOT use a modeline as it
+    is probably meant for human consumption.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-changes/attachments/20071202/8c2d8f18/attachment.html


More information about the macports-changes mailing list