8 | | 2. A commit affects one port (including however many files are required for that one port) |
9 | | 3. The exception to the one port/one commit rule is where several Portfiles make use of some feature which is in need of updating[[BR]] |
10 | | 3.1. Due to a new feature which has been added to the current release to fix hacks used by various Portfiles[[BR]] |
11 | | 3.2. A command is found to be broken[[BR]] |
12 | | 3.3. You need to change your email address for your ports[[BR]] |
13 | | 3.4. Other, similar reasons[[BR]] |
14 | | 4. All committers must subscribe to the [http://lists.macosforge.org/mailman/listinfo/macports-changes macports-changes] list under their MacPorts credentials to keep track of current changes and because the list is subscriber-post-only, so commit messages will otherwise be rejected |
15 | | 5. New top-level categories (those which are represented by directories in the MacPorts tree) need to be approved prior to adding; secondary categories (the second and later ones listed on the '''categories''' Portfile key) can be added when it makes sense (since these really only show under the web interface, and have no filesystem representation) |
16 | | 6. Make sure the port name matches between the MacPorts svn directory name and the '''name''' Portfile key (while the system works fine when they don't, keeping them synchronized avoids confusing situations) |
17 | | 7. Should commit logs be finally standardized? Some places have the CVS/Template which contains a few common headers (Bug:, Submitted By:, etc), but these are not always present or used for that matter |
18 | | 8. Under most circumstances, do not modify a port belonging to another maintainer; this is to be done either via a Trac ticket or by direct communication with the maintainer. Exceptions are: |
19 | | 8.1. When a port is broken (and the update should be just to fix the port, no other updates "while you're there")[[BR]] |
20 | | 8.2. When ''nomaintainer@macports.org'' is the maintainer; this really means the port is unowned (feel free to take it over)[[BR]] |
21 | | 8.3. When ''openmaintainer@macports.org'' is co-maintainer; this signifies that the primary maintainer has no prior objections to others changing it[[BR]] |
22 | | 8.4. When the maintainer says the update is okay and asks you to commit your update; in this case, be sure to note in the commit message that it was '''Approved by:''' the maintainer (see the bit about commit log entries above) |
| 8 | 1. A commit affects one port (including however many files are required for that one port) |
| 9 | 1. The exception to the one port/one commit rule is where several Portfiles make use of some feature which is in need of updating |
| 10 | 1. Due to a new feature which has been added to the current release to fix hacks used by various Portfiles |
| 11 | 1. A command is found to be broken |
| 12 | 1. You need to change your email address for your ports |
| 13 | 1. Other, similar reasons |
| 14 | 1. All committers must subscribe to the [http://lists.macosforge.org/mailman/listinfo/macports-changes macports-changes] list under their MacPorts credentials to keep track of current changes and because the list is subscriber-post-only, so commit messages will otherwise be rejected |
| 15 | 1. New top-level categories (those which are represented by directories in the MacPorts tree) need to be approved prior to adding; secondary categories (the second and later ones listed on the '''categories''' Portfile key) can be added when it makes sense (since these really only show under the web interface, and have no filesystem representation) |
| 16 | 1. Make sure the port name matches between the MacPorts svn directory name and the '''name''' Portfile key (while the system works fine when they don't, keeping them synchronized avoids confusing situations) |
| 17 | 1. Should commit logs be finally standardized? Some places have the CVS/Template which contains a few common headers (Bug:, Submitted By:, etc), but these are not always present or used for that matter |
| 18 | 1. Under most circumstances, do not modify a port belonging to another maintainer; this is to be done either via a Trac ticket or by direct communication with the maintainer. Exceptions are: |
| 19 | 1. When a port is broken (and the update should be just to fix the port, no other updates "while you're there") |
| 20 | 1. When ''nomaintainer@macports.org'' is the maintainer; this really means the port is unowned (feel free to take it over) |
| 21 | 1. When ''openmaintainer@macports.org'' is co-maintainer; this signifies that the primary maintainer has no prior objections to others changing it |
| 22 | 1. When the maintainer says the update is okay and asks you to commit your update; in this case, be sure to note in the commit message that it was '''Approved by:''' the maintainer (see the bit about commit log entries above) |