[[!meta title="Git merge policy: how to submit code"]]
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](https://salsa.debian.org/tails-team/tails).
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|contribute/working_together/roles/sysadmins]]
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](https://salsa.debian.org/tails-team/tails).
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
7. Set the ticket's *QA Check* field to *Ready for QA*.
8. Assign the ticket to nobody (aka. unassign it from yourself) by
default. Unless it's clear to you that nobody on the
[[Foundations Team|working_together/roles/foundations_team]] will be
able or willing to do this specific review; in that case, _you_ shall try
to find someone else to do the review, and assign the ticket
8. For important changes, if you feel the need to ask input from the
greater development community, notify the [[email@example.com|about/contact#tails-dev]]
Then, if the [[reviewer|contribute/merge_policy/review]] asks for more
development to be done before
merging, they should set the ticket's *QA Check* field back to *Needs
more dev* or *Needs more info* state, and
from now on it's the responsibility of the branch/ticket "holder" to
change it back to *Ready for QA* 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.