Commit 91df7ac9 authored by intrigeri's avatar intrigeri
Browse files

Update most of our doc wrt "[Tails-dev] Proposal: Redmine workflow change".

i.e. Message-Id: <87a7hkk19g.fsf@manticora>
parent 3a5f3861
......@@ -86,7 +86,7 @@ Each open issue must have one of these labels:
- "2. Doing" ("In progress" was too vague: it could mean anything
between "someone did the first 2% of the work 5 years ago" to "this is
what I'm focused on today")
- "3. To review" (previously "Ready for QA")
- "3. Needs Validation"
… except issues that were just created and need to be triaged by Help
Desk (previously: "New").
......@@ -175,7 +175,7 @@ For example:
- Every time one mentions me somewhere, I get a Todo item.
This allows me to track the questions I've been asked, that is, to
replace our usage of "Info Needed", without the need to reassign an
replace our past usage of "Info Needed", without the need to reassign an
issue or to create a subtask.
- I can click "Add todo" on an issue and it will appear on my list
......
......@@ -136,7 +136,7 @@ conflict, then the topic branch's developer should take care of resolving it.
Otherwise if it fails the developer who proposed the merge must be notified
And the developer *needs* to see the build logs
And the ticket should be reassigned to the branch submitter
And QA check should be set to "Dev needed"
And Status should be set to "In Progress"
Bonus:
......@@ -167,7 +167,7 @@ Bonus:
Otherwise if it fails I *need* to see the build logs
And the developer who proposed the merge must be notified
And the ticket should be reassigned to the branch submitter
And QA check should be set to "Dev needed"
And Status should be set to "In Progress"
## Scenario 3 : RM
......
......@@ -77,7 +77,7 @@ tests, as this jobs will be chained together.
Must test ISOs built daily and on every Git push;
so that we always know the state of the next release;
For other branches:
For branches with a `Ready for QA` ticket:
For branches with a `Needs Validation` ticket:
Must test ISO built daily and on every Git push;
Must test ISOs built on every Git push,
with some rate-limiting if necessary;
......@@ -165,7 +165,7 @@ builds specification.
Otherwise the developer who proposed the merge must be notified
And the developer *needs* to see the test logs and screenshots
And the ticket should be reassigned to the branch submitter
And QA check should be set to "Dev needed"
And Status should be set to "In Progress"
## Scenario 2 : developer
......@@ -182,7 +182,7 @@ builds specification.
Otherwise I *need* to see the build logs and screenshots
And I must be notified
And the ticket should be reassigned to me if needed
And QA check should be set to "Dev needed"
And Status should be set to "In Progress"
## Scenario 3 : RM
......@@ -200,7 +200,7 @@ builds specification.
## Cutting the number of run per day
For feature branches, we could run the full test suite only on the daily
builds or on ReadyForQA ones, and either only the automated tests
builds or on "Needs Validation" ones, and either only the automated tests
related to the branch on every git push, and/or a subset of the whole
test suite.
......
......@@ -14,7 +14,7 @@ soonish, and improvements are always welcome in the contributor UX
area:
* When Jenkins has built an ISO from one of our main branches or from
a branch that is _Ready for QA_, since October 2017 we rebuild in
a branch that _Needs Validation_, since October 2017 we rebuild in
in a slightly different build environment to ensure it can be
[[rebuilt reproducibly|blueprint/reproducible_builds]].
This increased substantially the number of ISO image we build
......@@ -289,7 +289,7 @@ and shuts them down after a configurable idle time.
After building an ISO, we copy artifacts from the ISO builder to the
Jenkins master (and thus to nightly.t.b.o), and then from the Jenkins
master to another ISO builder (if the branch is _Ready for QA_ or one
master to another ISO builder (if the branch _Needs Validation_ or one
of our main branches) and one ISO tester (in an case) that run
downstream jobs. These copies are blocking operations in our feedback
loop. So:
......
......@@ -69,10 +69,10 @@ your merge to our main [[Git repository|contribute/Git]]. For example:
## Book keeping
1. Update the *QA Check* field on the ticket. If there is no remaining
1. Update the *Status* field on the ticket. If there is no remaining
tasks listed on the ticket, then change its status to *Fix
committed* (unless you used the `fix-committed` keyword documented
above); else, ask the branch submitter to split the remaining tasks
into other tickets.
above); else, set it back to *In Progress* and ask the branch submitter
to split the remaining tasks into other tickets.
1. Push the updated branch to the master Git repository.
1. Reply to the email that requested the review, if any.
......@@ -26,7 +26,7 @@ When you think it is good enough and have tested it, you have to:
- 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*.
7. Set the ticket's *Status* field to *Needs Validation*.
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.
......@@ -40,10 +40,9 @@ When you think it is good enough and have tested it, you have to:
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
merging, they should set the ticket's *Status* field back to *In Progress*;
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
change it back to *Needs Validation* once they consider the issues raised by
the reviewer are fixed.
The reviewer is allowed to commit trivial fixes on top of the
......
......@@ -28,8 +28,7 @@ Subscribe to:
* the [*Fix
committed*](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=111)
feed;
* the [*Ready for
QA*](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=117) feed.
* the [*Needs Validation*](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=117) feed.
How to use Redmine's Atom feeds
-------------------------------
......@@ -112,6 +111,9 @@ Please take a time to see how we use the fields of Redmine:
- Added by Redmine automatically when a Git commit with `will-fix: #NNNN`
is added to the Tails repository. This keyword should be only used in
topic branches.
* Needs Validation
- Proposed changes are ready to be reviewed.
Read our [[merge policy|/contribute/merge_policy]] to know more.
* Fix committed:
- The fix has been merged into the [[main Tails Git repository|contribute/git#main-repo]].
- Added by Redmine automatically when a Git commit with `fix-committed: #NNNN`
......@@ -128,30 +130,13 @@ Please take a time to see how we use the fields of Redmine:
- It would be good to have it, but nobody is volunteering to do it.
* Elevated:
- Regressions are always marked as Elevated.
* Assignee:
- Assign yourself to a ticket if you are working on it to prevent duplicated
* Assignee: assign yourself to a ticket if you are working on it to prevent duplicated
work.
- Assign a ticket marking `QA check` as `Info needed` to get information from
someone.
* Category:
- This are usually transversal issues, not specific tools.
* Target version:
- The Tails release this ticket aims to be fixed for.
- If submitting code, the Tails release you would like your changes to be in.
* QA Check (quality assurance):
* Info Needed:
- If you want to work on this ticket but you need more information, select
this option, ideally along with an assignee and a note about what to do
after the information has been given (*reassign to you?*).
- Answering such tickets quickly when they are assigned to you is very
important to speed up development.
* Ready for QA:
- When your code is ready to fix this ticket, you can set this option, usually
accompanied by a Git branch to review.
Read our [[merge policy|/contribute/merge_policy]] to know more.
* Pass:
- When a reviewer has reviewed submitted code can set this field to pass,
and can be merged to `tails` repository.
* Feature Branch:
- Add the information of the branch for this issue in the format
`repositoryname:branch`, or only the branch name if it's on Tails repository.
......@@ -188,6 +173,20 @@ Please take a time to see how we use the fields of Redmine:
getting into Tails. [[Learn
more|/contribute/working_together/criteria_for_starter_tasks/]].
# Requesting input from someone else
If you want to work on a ticket but you need some input from someone
else, ask your question on a comment on the ticket, mentioning them
with their Redmine login name: `@nick`.
If you expect the person you're asking input from will need to do
substantial amounts of work to answer your question, you may file
a dedicated subtask assigned to them.
When input is requested from you this way, it's important to provide
it as quickly as you can, to make the Tails contribution process more
efficient and enjoyable.
# Core team's work
Some of the teams who do
......
......@@ -53,15 +53,15 @@ The Tails Foundations Team is responsible for:
* reviewing'n'merging proposed branches in a timely manner (1 week in
general, up to 2 weeks if needed in exceptional cases). If a ticket
is flagged *Ready for QA*, but nobody on the Foundations Team can
is flagged *Needs Validation*, but nobody on the Foundations Team can
take care of the review'n'merge, it's the Foundations Team's
responsibility to ask for help. These tickets can be tracked using:
- the "Release Manager View: VERSION";
- the
[Ready for QA, with no assignee](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=194)
[Needs Validation, with no assignee](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=194)
view;
- [Ready for QA](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=117);
- [Needs Validation](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=117);
* deal with last minute emergency fixes needed during release process,
e.g. [[!tails_ticket 14962]];
......
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