Changeset 31680 for trunk/base/HACKING


Ignore:
Timestamp:
Dec 3, 2007, 12:24:31 AM (13 years ago)
Author:
jberry@…
Message:

Hard wrap and detab HACKING file. Whitespace changes only.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/base/HACKING

    r31679 r31680  
    11# Project naming and copyright attribution:
    22
    3 * "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.
    4 * 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
    5   to an already existing source file in the "base" component of our repository.
    6 * 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
    7   down to a minimum
    8 * 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
    9   being uploaded to the "base" component of our repository, since as such they are being contributed to the project.
     3 *  "The MacPorts Project" is the string that shall be used whereever
     4    there's a need to reference our project name, such as in copyright
     5    notices.
     6
     7 *  A developer or contributor is advised to attribute himself a copyright
     8    notice if he/she is contributing a full new source file or a full
     9    new feature to an already existing source file in the "base"
     10    component of our repository.
     11
     12 *  An exception to this rule is our Portfiles, since they are partly
     13    meant for human eyes consumption and the boilerplate header comments
     14    should be kept down to a minimum
     15
     16 *  A copyright notice attributed to our group name, "The MacPorts
     17    Project", should also be added to these source files (if not already
     18    there) if they're being uploaded to the "base" component of our
     19    repository, since as such they are being contributed to the project.
    1020
    1121
    1222# Commits to the "base" component of the repository:
    1323
    14 * 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,
    15   with references to pertitent Trac ticket numbers and svn commit revisions where appropriate.
    16 * 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.
    17   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
    18   and Trac ticket number (if applicable).
    19 * Related commits to "base" should be grouped in a single ChangeLog entry.
    20 * 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.
     24 *  Commits with user-visible affect made to the "base" component of the
     25    repository should be accompanied by a corresponding entry in the
     26    base/ChanegeLog file, with references to pertitent Trac ticket
     27    numbers and svn commit revisions where appropriate.
     28
     29 *  Such entries to the ChangeLog need not be full duplications of their
     30    related commit logs if the latter are thorough explanations of
     31    what's involved in the commit. In such cases it's perfectly
     32    acceptable to enter just a summary of the commit and point the
     33    reader to further information through the related svn revision and
     34    Trac ticket number (if applicable).
     35
     36 *  Related commits to "base" should be grouped in a single ChangeLog
     37    entry.
     38
     39 *  Commits to "base" need not update the base/NEWS file, as such will be
     40    constructed with the relevant information at MacPorts release time
     41    by the release engineers.
    2142
    2243
    2344# Whitespace rules as discussed on the development list (macports-dev):
    2445
    25 * All source code files MUST use soft tabs at a tabstop of 4. No hard tabs are allowed.
    26 * All source code files SHOULD have the following as the first line of the file:
    27     # -*- 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
    28   This is a modeline that works for both emacs and vim.
    29 * Portfiles SHOULD use soft tabs at a tabstop of 4, but implementation of this is left up to the discretion of the maintainer.
    30 * Portfiles SHOULD use the given modeline
    31 * Makefiles MUST use tabs as it is required by the syntax. Makefiles SHOULD use a tab stop of 8.
    32 * Makefiles MAY use a modeline. The following works for emacs and vim:
    33     # -*- coding: utf-8; mode: Makefile; tab-width: 8; indent-tabs-mode: t -*- vim:fenc=utf-8:filetype=Makefile:noet:sw=8:ts=8
    34 * All other files (documentation, etc) SHOULD use soft tabs at a tabstop of 4 if the document format allows.
    35 * All other files (documentation, etc) SHOULD NOT use a modeline as it is probably meant for human consumption.
     46 *  All source code files MUST use soft tabs at a tabstop of 4. No hard
     47    tabs are allowed.
     48
     49 *  All source code files SHOULD have the following as the first line of
     50    the file:
     51       
     52        # -*- 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
     53       
     54    This is a modeline that works for both emacs and vim.
     55   
     56 *  Portfiles SHOULD use soft tabs at a tabstop of 4, but implementation
     57    of this is left up to the discretion of the maintainer.
     58
     59 *  Portfiles SHOULD use the given modeline
     60
     61 *  Makefiles MUST use tabs as it is required by the syntax. Makefiles
     62    SHOULD use a tab stop of 8.
     63
     64 *  Makefiles MAY use a modeline. The following works for emacs and vim:
     65 
     66        # -*- coding: utf-8; mode: Makefile; tab-width: 8; indent-tabs-mode: t -*- vim:fenc=utf-8:filetype=Makefile:noet:sw=8:ts=8
     67
     68 *  All other files (documentation, etc) SHOULD use soft tabs at a tabstop
     69    of 4 if the document format allows.
     70
     71 *  All other files (documentation, etc) SHOULD NOT use a modeline as it
     72    is probably meant for human consumption.
Note: See TracChangeset for help on using the changeset viewer.