wiki:CommittingYourChanges

Committing Your Changes

Before continuing:

NOTE: This document assumes that the remote named origin is the repository on git.mit.edu.

Non-Native Packages

For non-native packages, changes are broken into changes to the "upstream" code itself (on the master branch), or changes to the packaging (on the debian branch). For example, if  getcluster throws a Python exception, and you fix that, that would be a change to the code itself. If, on the other hand, you're just updating a dependency in the control file, then that's a change to the packaging only.

Changing master

  • Make your changes to the code to fix whatever bug you're fixing or add whatever feature you're adding.
  • Ensure that you update the software's version number as appropriate. Software is versioned in one of 3 places:
    • configure.ac -- in the AC_INIT macro
    • setup.py -- in the version keyword argument to the setup() function
    • VERSION -- a plain-text file at the top-level of the source tree containing a version number
  • Commit your changes, and push them to your remote. Submit a pull request as described here, and wait for code review, or decide that this is important enough that it doesn't need code review.

Once your pull request is approved (or you have decided to approve it yourself):

  • Tag your most recent commit with the version number (this MUST match the version number as described above).
    • git tag -a 10.0.3 a4b5c6d7
  • Push your master, and the tag to origin.
    • git push origin master
    • git push origin 10.0.3
    • Once you do this, the version is finalized. If you find a bug, you'll need to bump the version number and repeat this process.
  • Checkout the debian branch, and merge your changes into master, ensuring you get a merge commit, not a fast-forward
    • git checkout debian
    • git merge --no-ff master
  • Proceed to the next section to update the packaging.

Changing debian

  • Make any changes to the packaging
  • Ensure you add a new Debian changelog entry. (dch -v <version>; dch -r)
    • The upstream component of the version must match the tag in master, and the distro-specific component should be -0debathena1, incrementing the last digit as necessary, if there are packaging-only changes. For example, using version 10.0.3 as above, the entry in debian/changelog should be 10.0.3-0debathena1.
  • Commit your changes.
    • If the changes to packaging are more complicated than a new changelog entry (e.g. if you're changing maintainer scripts, or the rules file), push to your remote, submit another pull request, and wait for code review.
  • Push to origin:
    • git push origin debian

Native Packages

Reminder: Native packages have a single master branch, and are not tagged at commit time.

  • Make your changes to the code, and commit them.
  • Ensure you update the debian/changelog file with a new entry for the new version. Unlike non-native packages, version strings should just be numbers (e.g. 1.5.7).
  • Commit your changes, and push them to your remote. Submit a pull request as described here, and wait for code review, or decide that this is important enough that it doesn't need code review.
  • Once your pull request is approved, push to origin:
    • git push origin master