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 the developer thinks it is good enough and has tested it, she must:

  • 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!
  • set the ticket's Status field to In Progress (if you do not see this field when editing the ticket, ask the sysadmin team to grant you the necessary permissions)
  • set the ticket's QA Check field to Ready for QA
  • assign this ticket to nobody (aka. unassign it from yourself) by default. Unless it's clear to you that nobody on the 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.
  • point the ticket's Feature Branch field to your branch
  • set the ticket's Target version field to the release you would like your changes to be in
  • for important changes, if you feel the need to ask input from the greater development community, notify the mailing list

Then, if the reviewer 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.