[[!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. 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|working_together/roles/foundations_team]]
will either handle the review themselves or help you find a suitable
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.