1. Introduction
2. Installing MacPorts
2.1. Install Xcode
2.2. Install MacPorts
2.3. Upgrade MacPorts
2.4. Uninstall MacPorts
2.5. MacPorts and the Shell
3. Using MacPorts
3.1. The port Command
3.2. Port Variants
3.3. Common Tasks
3.4. Port Binaries
4. Portfile Development
4.1. Portfile Introduction
4.2. Creating a Portfile
4.3. Example Portfiles
4.4. Port Variants
4.5. Patch Files
4.6. Local Portfile Repositories
4.7. Portfile Best Practices
4.8. MacPorts' buildbot
5. Portfile Reference
5.1. Global Keywords
5.2. Global Variables
5.3. Port Phases
5.4. Dependencies
5.5. Variants
5.6. Tcl Extensions & Useful Tcl Commands
5.7. StartupItems
5.8. Livecheck / Distcheck
5.9. PortGroups
6. MacPorts Internals
6.1. File Hierarchy
6.2. Configuration Files
6.3. Port Images
6.4. APIs and Libs
6.5. The MacPorts Registry
6.6. Tests
7. MacPorts Project
7.1. Using Trac for Tickets
7.2. Using Git and GitHub
7.3. Contributing to MacPorts
7.4. Port Update Policies
7.5. Updating Documentation
7.6. MacPorts Membership
7.7. The PortMgr Team
8. MacPorts Guide Glossary
Glossary

7.4. Port Update Policies

Port maintainers normally are given commit privileges to the Git repository so they can make updates to their own ports as described in Section 7.6, “MacPorts Membership”. However, The MacPorts Project does not restrict commit privileges for maintainers, so before a person other than a port's maintainer updates a port it is a good practice to inform a port's maintainer. See details below.

7.4.1. Non-Maintainer Port Updates

If you have a port update or bugfix for a port you do not maintain, to respect the rights of the port maintainer you should follow the following guidelines:

  1. If a port's maintainer is , you may feel free to make updates and/or take maintainership of the port.

  2. If a port's maintainer contains the address , this means that the author allows minor updates to the port by other committers without contacting them first. But permission should still be sought for major changes.

    Committers are expected to investigate as thoroughly as necessary to confirm that an update is in fact minor. Some projects have made quite major changes with only a tiny change to the version number. And of course a committer should always verify that a port not only builds but works correctly after a change, before pushing it.

    Pull requests for maintained ports should not be merged by anyone other than their creator or the port maintainer until the 72-hour timeout period has passed, even if the port is openmaintainer. This is because the change is either from a non-committer, or from a committer who could have just pushed the change directly, and by opening a PR is signalling a desire to have the change reviewed by the maintainer.

  3. Create patch file(s) as necessary, attach them to a Trac ticket, and assign the ticket to the maintainer (or Cc the maintainer, if you are unable to assign tickets).

  4. Wait for a response from the maintainer. The maintainer should apply the patches and close the ticket within 72 hours.

However, for maintained ports without , there are some conditions under which maintainer permission may be waived:

  • If the maintainer does not respond within 72 hours, you or another committer may review the patches and update the port. The log message of this commit must explain that you are taking advantage of maintainer timeout and include a reference to the ticket. If you are not a committer you may send an email to and request the updates be committed.

  • A port is abandoned by its current maintainer. A port against which a Port Abandoned ticket has been filed (see below) can be updated without contacting the maintainer.

  • A critical port is broken that affects many users.

7.4.2. Port Abandonment

A port may be considered abandoned if any of the following apply:

  • A bug has not been acknowledged for more than three weeks after a ticket is filed.

  • All tickets (and/or pull requests) filed against the port have been resolved with no input from the maintainer, after the 72-hour timeout, for a significant period of time (at least three weeks). This needs to involve a reasonable number of tickets; one timeout doesn't make a port abandoned.

  • The listed maintainer address bounces, and no alternate way of contacting the maintainer is known.

If you wish to initiate the Port Abandonment protocol and optionally volunteer as the new maintainer:

  1. File a new Trac ticket with the summary line: [Port Abandoned] portname.

  2. The ticket should be assigned to the maintainer. Non-macports team members should Cc the maintainer.

  3. Set the ticket Type to Defect.

  4. In the Description field, refer to any unacknowledged ticket(s).

  5. In the Port field, indicate which port is abandoned.

  6. The Port Abandoned ticket may be closed when the new maintainer is assigned, and the original ticket(s) with the updates may be resolved as usual. The former maintainer should be removed from all other tickets on which they were assigned as owner. The Port Abandoned ticket should stay open for the usual 72-hour timeout period, to give the maintainer one last chance to indicate that they have not actually abandoned the port.