Commit f91a3b4f authored by intrigeri's avatar intrigeri
Browse files

GitLab: adjust lots of phrasing

parent 7be29798
......@@ -60,7 +60,7 @@ automatically if the ABI is bumped.
# Process
A Foundations Team member (generally the team lead, so far) creates
a tracking ticket whenever:
a tracking issue whenever:
- A new major version of Linux is released. At this point, that
version is generally available only in Debian _experimental_.
......@@ -91,12 +91,10 @@ To learn how the new kernel works for us:
back to the top level directory. `git diff` should show an updated
`Subproject commit` accordingly, and that can be committed.
3. Push this new branch to our CI.
4. Set the _Feature Branch_ field on the ticket to the name of your
new branch.
5. Quickly test a build from this branch on your hardware.
6. Compare the Jenkins build and test results to the ones for our
`stable` and `devel` branch.
7. Report your findings on the ticket.
7. Report your findings on the issue.
## Gather other data that will inform our decision
......@@ -121,7 +119,7 @@ In there, look for:
recently reported to Debian against this version of the kernel
- Relevant hardware support improvements
Take notes on the ticket of the most relevant bits or lack thereof.
Take notes on the issue of the most relevant bits or lack thereof.
## Make a decision
......@@ -144,7 +142,7 @@ several factors:
If in doubt, ask your team-mates :)
If the decision is "do nothing", close the ticket and stop reading here.
If the decision is "do nothing", close the issue and stop reading here.
Else, read on.
## Implement the decision
......@@ -160,8 +158,7 @@ Therefore, create a new
`feature/NNNNN-linux-X.Y-stable+force-all-tests` topic branch forked
off `stable` and transplant onto it the commits you had to create on
your `devel`-based topic branch (`git rebase --onto` or `git
cherry-pick`). Update the _Feature Branch_ field accordingly
in Redmine.
cherry-pick`).
But the new resulting topic branch will likely not build: a bugfix
release is built from our `stable` branch, that uses a set of APT
......@@ -230,8 +227,9 @@ improvement:
- Enabled by default: nothing to do, profit :)
- Guarded by local configuration such as a sysctl or a kernel command
line option: file a ticket about it on Redmine and add this ticket
to the Foundations Team' radar. Optionally, do the work yourself:
line option: file a GitLab issue about it, with the
`Core work: Foundations Team` label.
Optionally, do the work yourself:
once you've got CI results about your topic branch with this new
option disabled, add a commit that enables it and compare the
results (including test suite total run time, to spot important
......
......@@ -60,7 +60,7 @@ upstream... which sometimes implies to write a patch ourselves.
We use [[!tails_gitlab "" desc="GitLab"]] to track
our lists of tasks and bugs, as well as our [[!tails_roadmap]].
If you already know which one of the listed tasks you want to tackle
and it has the *Code* Type of work, then you can probably
and it has the *T:Code* label, then you can probably
safely skip to the next section.
So you want to contribute code to Tails but do not know where to
......
......@@ -44,7 +44,7 @@ you have something to contribute, please read our
* `feature/XXXX-*`, `bugfix/XXXX-*`, `test/XXXX-*`: We use this naming
scheme for the branches if new features, bugfixes and automated
tests, where `XXXX` refers to the Redmine ticket they fix.
tests, where `XXXX` refers to the GitLab issue they fix.
We will sometimes talk about "base branches", which are `stable`,
`testing`, `devel` and `feature/DEBIAN_NEXT`. When developing a new
......
......@@ -25,7 +25,7 @@ But there are still many ways you can start contributing:
- We maintain a list of
[[!tails_gitlab groups/tails/-/issues?label_name%5B%5D=T%3AEnd-user+documentation
desc="documentation tasks"]].
You can start writing a draft in the corresponding ticket and then
You can start writing a draft in the corresponding issue and then
[[ask us for review|contribute/merge_policy]].
- Small fixes and enhancements to the current documentation are
......
......@@ -56,7 +56,7 @@
understandable by them.
- What we are describing in non-technical language is
understandable by more technical users.
- We point to more technical sources like tickets and design
- We point to more technical sources like issues and design
documents.
- Technical items are less proheminent.
- *For example:* Harden our firewall by rejecting `RELATED` packets
......@@ -77,14 +77,14 @@
- Add regressions brought by the new release.
- Remove older known issues that are fixed by the new release.
- Format
- Link to ticket for fixed problems and changes that are well justified in Redmine
- Put the period before ticket number
- Link to issue for fixed problems and changes that are well justified in GitLab
- Put the period before issue number
- "Bla bla. ([!tails_ticket 1234])"
- Prepare a tweet with highlights:
- Tails x.y is out: https://tails.boum.org/news/version_x.y/
It bla bla bla, and more.
- Add it as a comment to the ticket for the release notes.
- Add it as a comment to the issue for the release notes.
- If we release new major features ("New features" section),
schedule tweets in the future to let the world know about it, even
months after we release them.
......
......@@ -9,7 +9,7 @@ who lack the technical skills needed to actually implement the desired
feature.
Tasks that are currently stalled by the need for input have the
the `Research`, `Discuss`, or `Test` *Type of work* on our
the `T:Research`, `T:Discuss`, or `T:Test` label on our
[[!tails_gitlab "" desc="TODO"]] list.
You probably want to start looking at the ones that are also in the
[[!tails_gitlab_starter]] first so that you can gain confidence...
......
......@@ -75,7 +75,7 @@ contribute usefully without having an account on the actual systems.
## If you don't know Puppet
A few issues in GitLab can be fulfilled by testing something, and then
reporting your results on the relevant ticket.
reporting your results on the relevant issue.
However, most tasks are a bit more complicated. Follow these steps to
contribute useful bits, that someone else can then integrate into
......
......@@ -57,7 +57,7 @@ In particular, see
- As reviewer, you are allowed to commit trivial fixes on top of the
proposed branch to avoid round-trips: for example, fixing typos
and improving phrasing of comments and strings.
Then, report back about these changes on the ticket.
Then, report back about these changes on the MR.
## Give feedback
......
......@@ -730,7 +730,7 @@ to verify that Jenkins reproduced your images:
* Otherwise, if the fix looks time-consuming or difficult,
let's release anyway. But let's add a known issue about
"This Tails release does not build reproducibility" to the
release notes, linking to the ticket where
release notes, linking to the issue where
the nature of the reproducibility failure is clearly
described.
......@@ -954,7 +954,7 @@ Else, if this verification fails, then:
Else, if the parameters where correct, then follow the next steps.
3. File a ticket about this problem.
3. File an issue about this problem.
Specify:
......@@ -1294,7 +1294,7 @@ Testing
suites are done in due time. Clock and report this work separately
from your RM'ing work.
1. Triage test results, reproduce bugs as needed, decide what the next
step is and make sure it happens: add to known issues? file ticket?
step is and make sure it happens: add to known issues? file an issue?
release blocker? improve the test description (steps, expected outcome)?
Prepare announcements and blog posts
......@@ -1394,7 +1394,7 @@ Write the announcement for the release in
[[!tails_gitweb_commit 9925321]] breaks all existing persistent
profiles).
- Document known issues.
- This snippet can help to convert the copied changelog's ticket
- This snippet can help to convert the copied changelog's issue
references to links:
sed -i 's@#\([0-9]\{4,5\}\)@[[!tails_ticket \1]]@g' \
......@@ -1581,14 +1581,16 @@ you've just released:
Then, do the same for MRs.
Ideally we would [[!tails_ticket 17589 desc="automate this"]].
Then, close the just-released [[!tails_gitlab groups/tails/-/milestones
desc="milestone"]].
### Tickets linked from the website
Go through the tickets linked from the documentation and support sections of the
website and point our lead technical writer (sajolida) to the tickets that might be resolved in
this release.
Go through the issues linked from the documentation and support sections of the
website and point our lead technical writer (sajolida) to those that might
be resolved in this release.
cd "${MASTER_CHECKOUT:?}" && \
find wiki/src/{doc,support} -name "*.mdwn" -o -name "*.html" | xargs cat | \
......@@ -1620,7 +1622,7 @@ span several lines, so finding the ones reported by the above code
Twitter
-------
Check in the comments of the ticket for the release notes if the
Check in the comments of the issue for the release notes if the
technical writers have prepared a tweet. Otherwise tweet a simple link
to the release notes:
......
......@@ -189,8 +189,6 @@ Also:
package meant for the Tails APT repository, while the first package
that will be uploaded to Debian will have `-1`;
* Set the appropriate target release name.
* Make sure every Tails ticket ID is of the form `Tails#NNNNN`, not
`#NNNNN` and definitely not `Closes: #NNNNN`.
Commit the changelog:
......
......@@ -388,10 +388,8 @@ could either:
* remove a complete feature, if the complete feature is broken for the
same reason.
Each such commit *must* have a ticket created, referencing the commit
to revert, have an assignee and an appropriate milestone set so they
are not forgotten. Bonus point: push a branch that reverts the commit,
and then set it as the ticket's _Feature Branch_.
Each such commit *must* have an issue created, referencing the commit
to revert.
(Once [[!tails_ticket 10198]] has hit Cucumber we can solve this,
i.e. [[!tails_ticket 7233]], in a much better way.)
......@@ -6,8 +6,8 @@ After accepting to be the <i>Trusted Reproducer</i> you should have been
instructed to go here immediately and read the "Preparation"
section. For a planned release you should be doing this weeks before
the release you are about to reproduce; for emergency releases you
likely only have days or even hours. If you were not, file a
ticket about this, since an important part of process must have been
likely only have days or even hours. If you were not, file an
issue about this, since an important part of process must have been
missed by the RM.
</div>
......@@ -63,8 +63,8 @@ following variables as instructed:
<!-- variable|contribute/release_process#prepare-iuk]] and double-check -->
<!-- that it makes sense! Note that exceptions happen (e.g. there could -->
<!-- be a bug in some old versions upgrader so we skip it). -->
<!-- * If the release notes have already been written (generally there is a -->
<!-- ticket about it) it should list which versions have automatic upgrades. -->
<!-- * If the release notes have already been written (generally there is an -->
<!-- issue about it) it should list which versions have automatic upgrades. -->
## Inputs from manual testers
......
......@@ -32,8 +32,6 @@ the upgrade:
2. On that branch, bump `config/APT_snapshots.d/torproject/serial` to a snapshot
that's recent enough to include the relevant new version of `tor`.
3. Push this new branch to our CI.
4. Set the _Feature Branch_ field on the tracking issue to the name of your
new branch.
5. Compare the Jenkins build and test results to the ones for our
`stable` branch. What follows assumes that these CI results look good.
If they don't, more work is needed.
......
......@@ -128,7 +128,7 @@ met:
- Sponsor deliverables that are managed under the "let's decide
a long time in advance who exactly will do each task" paradigm.
- It is about the parent ticket for a large project with several
- It is about the parent tracking issue for a large project with several
subtasks that will be tackled by different people, and we need
someone to coordinate the project.
......
[[!meta title="Marking a task as Starter"]]
We think that having issues flagged as *Starter* on Redmine is a great tool
We think that having issues labeled *Starter* on GitLab is a great tool
to help new contributors getting into Tails. Here are a few criteria to
help us determine which issues to put in this category.
......
......@@ -33,7 +33,7 @@ User support
1. Gather information about the context in which the problem
occurs, how important it is, what known workarounds exist.
2. Forward the WhisperBack report over email.
3. File a ticket assigned to a Foundation Team member, referencing
3. File an issue assigned to a Foundation Team member, referencing
the WhisperBack report ID.
4. Ideally, provide statistics about how many people are impacted.
5. The Foundations Team will take a look and decide what to do
......
......@@ -45,7 +45,9 @@ and filing tickets for the Foundations Team as needed.
`README`
- follow the instructions in `keyringer/README` in the RM team's Git
repository then make sure you can `keyringer tails-rm decrypt credentials`
- _Manager_ status on Redmine
- _Reporter_ status on
[[!tails_gitlab groups/tails/-/group_members
desc="the `tails` GitLab group"]]
- Check when our OpenPGP signing key expires.
If that's before, or soon after, the scheduled date for the release
_after_ the one your shift is about, then shout.
......@@ -59,8 +61,8 @@ and filing tickets for the Foundations Team as needed.
- Ensure you have found a _Trusted Reproducer_ and write who this is
in the [[contribute/calendar]].
- Create a Foundations Team ticket about upgrading Tor Browser
in the release your shift is about.
- Create an issue with the `Core Work: Foundations Team` label,
about upgrading Tor Browser in the release your shift is about.
- Check if you have enough manual testers registered.
If not, ping the usual testers.
......
......@@ -91,7 +91,7 @@ use the ISO being tested instead of the last released one:
ISO being tested (instead of the last released one) to
`run_test_suite`'s `--old-iso` argument.
2. File a ticket to ensure this temporarily change gets reverted
2. File an issue to ensure this temporarily change gets reverted
in due time.
## Restarting slave VMs between test suite jobs
......
......@@ -24,6 +24,6 @@
- This does not cover the UX work related to deliverables for
grants which have a dedicated budget.
- Handle new Redmine tickets that are about feature requests and the
- Handle new GitLab issues that are about feature requests and the
scope of Tails. Reassign to whoever is on Help Desk duty any new
ticket that's really a support request.
issue that's really a support request.
......@@ -92,7 +92,7 @@ $FAMILY_NAME
------------
$LT!--
Tickets: #XXXXX #XXXXX
Issues: #XXXXX #XXXXX
--$GT
### Affected graphics cards
......@@ -114,7 +114,7 @@ AMD Radeon HD
-------------
<!--
Tickets: #11095 #12482
Issues: #11095 #12482
-->
### Affected graphics cards
......@@ -149,7 +149,7 @@ AMD Radeon R9
-------------
<!--
Tickets: #12218 #11850
Issues: #12218 #11850
-->
### Affected graphics cards
......@@ -171,8 +171,8 @@ Intel
-----
<!--
Ticket: #12219
Ticket: #16224
Issue: #12219
Issue: #16224
-->
### Affected graphics cards
......@@ -207,7 +207,7 @@ Intel 855GM
-----------
<!--
Ticket: #11096, Debian #776911
Issue: #11096, Debian #776911
-->
......@@ -224,7 +224,7 @@ Nvidia NV50 family (Tesla)
--------------------------
<!--
Ticket: #15491
Issue: #15491
-->
### Affected graphics cards
......@@ -317,7 +317,7 @@ Nvidia NV110 family (Maxwell)
-----------------------------
<!--
Ticket: #15116
Issue: #15116
-->
### Affected graphics cards
......@@ -389,7 +389,7 @@ Nvidia NV130 family (Pascal)
----------------------------
<!--
Ticket: #15116
Issue: #15116
-->
<!--
......@@ -530,7 +530,7 @@ There are several possible workarounds for this issue:
sudo passwd
For more details, see our ticket on [[!tails_ticket 7505 desc="Video is broken with switchable graphics"]].
For more details, see our issue on [[!tails_ticket 7505 desc="Video is broken with switchable graphics"]].
<a id=sg-segfault></a>
......@@ -554,7 +554,7 @@ Intel GM965/GL960
-----------------
<!--
Ticket: #12217, Linux #187001
Issue: #12217, Linux #187001
-->
### Affected graphics cards
......
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