summaryrefslogtreecommitdiffstats
path: root/wiki/src/contribute/merge_policy/submit.mdwn
blob: 29c406e9bd2e2a64fb017bdd6c9e5a3802d45ede (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
[[!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. If you have access to our Jenkins instance (if you don't know what
   this means, you do not) please make sure that your branch has not
   broken any tests! Or, if you only want a first review of your code,
   without bothering with the build & test status on Jenkins, that's fine:
   make it clear to the reviewer what you expect and
   that your branch is not ready to merge.
6. Set the ticket's *QA Check* field to *Ready for QA*.
7. 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
   to them.
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.