Commit e1b115b6 authored by Tails developers's avatar Tails developers
Browse files

Document new rules for review'n'merge sharing.

parent 534dee92
......@@ -6,10 +6,15 @@ When the developer thinks it is good enough and has tested it, she must:
- merge the topic branch into the `experimental` one
- 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 the current RM won't 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.
- set the ticket's *Feature Branch* field
- set the ticket's *Target version* field to the release you would
like your changes to be in
- ask the Release Managers to review and merge (in devel generally, in testing
- ask for a review and merge (in devel generally, in testing
or stable for bugfixes) by writing to the ``
......@@ -2,6 +2,8 @@
## Review
- When you start doing a review'n'merge, assign the relevant ticket to
you, in order to avoid duplicated work.
- Build the branch (or experimental) and test the feature.
- Check the diff e.g. with `git log -p`.
- Check the APT suite with
......@@ -43,6 +43,14 @@
do whatever is needed to get the fixes we need in the release.
- Have Kill Your TV upgrade I2P if needed. See [[contribute/design/I2P]].
## Continuously
The RM is still the fallback for reviewing'n'merging stuff relatively
promptly. If a ticket is flagged "Ready for QA", but the RM cannot or
doesn't want to take care of the review'n'merge, it's the RM's
responsibility to ask for help. The "Release Manager View" is probably
the best place to track such tickets.
## Make the release happen
No kidding. See [[contribute/release_process]].
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment