| 1 | |
|---|
| 2 | |
|---|
| 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. |
|---|
| 20 | |
|---|
| 21 | |
|---|
| 22 | |
|---|
| 23 | |
|---|
| 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. |
|---|
| 42 | |
|---|
| 43 | |
|---|
| 44 | |
|---|
| 45 | |
|---|
| 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 | |
|---|
| 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 | |
|---|
| 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. |
|---|