summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorintrigeri <intrigeri@boum.org>2019-06-02 14:13:49 +0000
committerintrigeri <intrigeri@boum.org>2019-06-02 14:13:49 +0000
commit91df7ac961a24bfcad7a66e19933f89e995774e5 (patch)
treec481f84b54ebad6d3b68ef5060b8182f39974154
parent3a5f3861f033a85c7a0e1a7a898c51a0b91b41b0 (diff)
Update most of our doc wrt "[Tails-dev] Proposal: Redmine workflow change".
i.e. Message-Id: <87a7hkk19g.fsf@manticora>
-rw-r--r--wiki/src/blueprint/GitLab.mdwn4
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/autobuild_specs.mdwn4
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/automated_tests_specs.mdwn8
-rw-r--r--wiki/src/blueprint/hardware_for_automated_tests_take3.mdwn4
-rw-r--r--wiki/src/contribute/merge_policy/review.mdwn6
-rw-r--r--wiki/src/contribute/merge_policy/submit.mdwn7
-rw-r--r--wiki/src/contribute/working_together/Redmine.mdwn39
-rw-r--r--wiki/src/contribute/working_together/roles/foundations_team.mdwn6
8 files changed, 38 insertions, 40 deletions
diff --git a/wiki/src/blueprint/GitLab.mdwn b/wiki/src/blueprint/GitLab.mdwn
index adc8ace..a7f3409 100644
--- a/wiki/src/blueprint/GitLab.mdwn
+++ b/wiki/src/blueprint/GitLab.mdwn
@@ -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
diff --git a/wiki/src/blueprint/automated_builds_and_tests/autobuild_specs.mdwn b/wiki/src/blueprint/automated_builds_and_tests/autobuild_specs.mdwn
index 5754d5e..8d87a7e 100644
--- a/wiki/src/blueprint/automated_builds_and_tests/autobuild_specs.mdwn
+++ b/wiki/src/blueprint/automated_builds_and_tests/autobuild_specs.mdwn
@@ -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
diff --git a/wiki/src/blueprint/automated_builds_and_tests/automated_tests_specs.mdwn b/wiki/src/blueprint/automated_builds_and_tests/automated_tests_specs.mdwn
index 5df035b..4968aeb 100644
--- a/wiki/src/blueprint/automated_builds_and_tests/automated_tests_specs.mdwn
+++ b/wiki/src/blueprint/automated_builds_and_tests/automated_tests_specs.mdwn
@@ -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.
diff --git a/wiki/src/blueprint/hardware_for_automated_tests_take3.mdwn b/wiki/src/blueprint/hardware_for_automated_tests_take3.mdwn
index 6ad5837..e7f5b3d 100644
--- a/wiki/src/blueprint/hardware_for_automated_tests_take3.mdwn
+++ b/wiki/src/blueprint/hardware_for_automated_tests_take3.mdwn
@@ -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:
diff --git a/wiki/src/contribute/merge_policy/review.mdwn b/wiki/src/contribute/merge_policy/review.mdwn
index b7a4743..7056d6e 100644
--- a/wiki/src/contribute/merge_policy/review.mdwn
+++ b/wiki/src/contribute/merge_policy/review.mdwn
@@ -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.
diff --git a/wiki/src/contribute/merge_policy/submit.mdwn b/wiki/src/contribute/merge_policy/submit.mdwn
index 945a405..9e31fc5 100644
--- a/wiki/src/contribute/merge_policy/submit.mdwn
+++ b/wiki/src/contribute/merge_policy/submit.mdwn
@@ -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
diff --git a/wiki/src/contribute/working_together/Redmine.mdwn b/wiki/src/contribute/working_together/Redmine.mdwn
index 8f88784..e02fedb 100644
--- a/wiki/src/contribute/working_together/Redmine.mdwn
+++ b/wiki/src/contribute/working_together/Redmine.mdwn
@@ -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
diff --git a/wiki/src/contribute/working_together/roles/foundations_team.mdwn b/wiki/src/contribute/working_together/roles/foundations_team.mdwn
index 8428622..a957c16 100644
--- a/wiki/src/contribute/working_together/roles/foundations_team.mdwn
+++ b/wiki/src/contribute/working_together/roles/foundations_team.mdwn
@@ -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]];