= Committing Your Changes = Before continuing: * ensure you have [wiki:WorkingWithGithub set up your fork and remote] for the module you're working on. * ensure you have read [wiki:WorkingWithTheRepository], especially the part on native vs non-native packages, deatched HEADs, and branches. **NOTE**: This document assumes that the remote named `origin` is the repository on `git.mit.edu`. == Native Packages == For 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 [https://github.com/mit-athena/getcluster 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 [wiki:WorkingWithGithub 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. * 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, and submit another pull request. * 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 [wiki:WorkingWithGithub 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`