wiki/src/contribute/merge_policy/submit.mdwn

   1 [[!meta title="Git merge policy: how to submit code"]]
   2
   3 All development should happen in topic branches. For a new feature XXX, it should
   4 be named `feature/XXX`. For a bugfix about YYY, it should be named
   5 `bugfix/YYY`. Ideally, include the relevant ticket number in the topic
   6 branch name, e.g. `bugfix/7173-upgrade-syslinux`.
   7
   8 When the developer thinks it is good enough and has tested it, she must:
   9
  10 - if you have the commit bit, merge the topic branch into the `experimental` one
  11 - set the ticket's *Status* field to *In Progress*
  12 - set the ticket's *QA Check* field to *Ready for QA*
  13 - assign this ticket to nobody (aka. unassign it from yourself) by
  14   default. Unless it's clear to you that the current release manager won't be able
  15   or willing to do this specific review; in that case, _you_ shall try
  16   to find someone else to do the review, and assign the ticket
  17   to them.
  18 - set the ticket's *Feature Branch* field
  19 - set the ticket's *Target version* field to the release you would
  20   like your changes to be in
  21 - ask for a review and merge (into devel generally, into testing
  22   or stable for bugfixes) by writing to the `tails-dev@boum.org`
  23   mailing-list
  24
  25 Then, if the [[reviewer|contribute/merge_policy/review]] asks for more
  26 development to be done before
  27 merging, they should set the ticket's *QA Check* field back to *Needs
  28 more dev* or *Needs more info* state, and
  29 from now on it's the responsibility of the branch/ticket "holder" to
  30 change it back to *Ready for QA* once they consider the issues raised by
  31 the reviewer are fixed.