summaryrefslogtreecommitdiffstats
path: root/wiki/src/contribute/merge_policy/submit.mdwn
blob: 945a4054712b0d9e2be056827b10cc869b51bd4b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
[[!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
     on Jenkins.
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
     reviewer.
8. For important changes, if you feel the need to ask input from the
   greater development community, notify the [[tails-dev@boum.org|about/contact#tails-dev]]
   mailing list.

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.