All development should happen in topic branches. For a new feature XXX, it should be named feature/XXX. For a bugfix about YYY, it should be named bugfix/YYY. Ideally, include the relevant ticket number in the topic branch name, e.g. bugfix/7173-upgrade-syslinux.

When you think it is good enough and have tested it, you have to:

  1. Push your branch
    • If you have commit access to the official Tails Git repository, push your branch there so our CI picks it up.
    • Else, push to your personal Git repository: fork us on Salsa.
  2. Set the ticket's Status field to In Progress (if you do not see this field when editing the ticket, ask the sysadmin team to grant you the necessary permissions).
  3. Point the ticket's Feature Branch field either to your branch or to a merge request on Salsa.
  4. Set the ticket's Target version field to the release you would like your changes to be in.
  5. Make it clear what you're requesting: merging? some advice? an initial code review of work that's not finished yet?
  6. If you have access to our Jenkins instance and you are requesting a merge:
    • Ensure your branch builds on Jenkins.
    • Either report about the test suite scenarios you've seen pass successfully locally, or check that the test suite passes on Jenkins.
  7. Set the ticket's Status field to Needs Validation.
  8. Set the ticket's Assignee field appropriately:
    • If it's already obvious to you who can and should review your branch: assign the ticket to this person.
    • Else, assign the ticket to nobody, i.e. unassign it from yourself. The Foundations Team will either handle the review themselves or help you find a suitable reviewer.
  9. For important changes, if you feel the need to ask input from the greater development community, notify the mailing list.

Then, if the reviewer asks for more development to be done before merging, they should set the ticket's Status field back to In Progress; from now on it's the responsibility of the branch/ticket "holder" to change it back to Needs Validation once they consider the issues raised by the reviewer are fixed.

The reviewer is allowed to commit trivial fixes on top of the proposed branch to avoid round-trips: for example, fixing typos and improving phrasing of comments and strings. They must report back about these changes on the ticket.