Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
tails
tails
Commits
f91a3b4f
Commit
f91a3b4f
authored
Apr 04, 2020
by
intrigeri
Browse files
GitLab: adjust lots of phrasing
parent
7be29798
Changes
20
Hide whitespace changes
Inline
Side-by-side
wiki/src/contribute/Linux_kernel.mdwn
View file @
f91a3b4f
...
...
@@ -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
...
...
wiki/src/contribute/how/code.mdwn
View file @
f91a3b4f
...
...
@@ -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
...
...
wiki/src/contribute/how/code/HACKING.mdwn
View file @
f91a3b4f
...
...
@@ -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
...
...
wiki/src/contribute/how/documentation.mdwn
View file @
f91a3b4f
...
...
@@ -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
...
...
wiki/src/contribute/how/documentation/release_notes.mdwn
View file @
f91a3b4f
...
...
@@ -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
ticket
s and design
- We point to more technical sources like
issue
s 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.
...
...
wiki/src/contribute/how/input.mdwn
View file @
f91a3b4f
...
...
@@ -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...
...
...
wiki/src/contribute/how/sysadmin.mdwn
View file @
f91a3b4f
...
...
@@ -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
...
...
wiki/src/contribute/merge_policy/review.mdwn
View file @
f91a3b4f
...
...
@@ -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
...
...
wiki/src/contribute/release_process.mdwn
View file @
f91a3b4f
...
...
@@ -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 a
n 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
ticket
s 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
issue
s linked from the documentation and support sections of the
website and point our lead technical writer (sajolida) to th
os
e 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:
...
...
wiki/src/contribute/release_process/tails-installer.mdwn
View file @
f91a3b4f
...
...
@@ -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
:
...
...
wiki/src/contribute/release_process/test/automated_tests.mdwn
View file @
f91a3b4f
...
...
@@ -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.)
wiki/src/contribute/release_process/test/reproducibility.mdwn
View file @
f91a3b4f
...
...
@@ -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 a
n
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 a
n
-->
<!--
issue
about it) it should list which versions have automatic upgrades. -->
## Inputs from manual testers
...
...
wiki/src/contribute/tor.mdwn
View file @
f91a3b4f
...
...
@@ -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.
...
...
wiki/src/contribute/working_together/GitLab.mdwn
View file @
f91a3b4f
...
...
@@ -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 t
icket
for a large project with several
- It is about the parent t
racking issue
for a large project with several
subtasks that will be tackled by different people, and we need
someone to coordinate the project.
...
...
wiki/src/contribute/working_together/criteria_for_starter_tasks.mdwn
View file @
f91a3b4f
[[!meta title="Marking a task as Starter"]]
We think that having issues
f
la
gged as
*Starter* on
Redmine
is a great tool
We think that having issues la
beled
*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.
...
...
wiki/src/contribute/working_together/roles/help_desk.mdwn
View file @
f91a3b4f
...
...
@@ -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 a
n 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
...
...
wiki/src/contribute/working_together/roles/release_manager.mdwn
View file @
f91a3b4f
...
...
@@ -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 a
n 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.
...
...
wiki/src/contribute/working_together/roles/sysadmins/automated_tests_in_Jenkins.mdwn
View file @
f91a3b4f
...
...
@@ -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 a
n issue
to ensure this temporarily change gets reverted
in due time.
## Restarting slave VMs between test suite jobs
...
...
wiki/src/contribute/working_together/roles/ux.mdwn
View file @
f91a3b4f
...
...
@@ -24,6 +24,6 @@
- This does not cover the UX work related to deliverables for
grants which have a dedicated budget.
- Handle new
Redmine ticket
s that are about feature requests and the
- Handle new
GitLab issue
s 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.
wiki/src/support/known_issues/graphics.mdwn
View file @
f91a3b4f
...
...
@@ -92,7 +92,7 @@ $FAMILY_NAME
------------
$LT!--
Ticket
s: #XXXXX #XXXXX
Issue
s: #XXXXX #XXXXX
--$GT
### Affected graphics cards
...
...
@@ -114,7 +114,7 @@ AMD Radeon HD
-------------
<!--
Ticket
s: #11095 #12482
Issue
s: #11095 #12482
-->
### Affected graphics cards
...
...
@@ -149,7 +149,7 @@ AMD Radeon R9
-------------
<!--
Ticket
s: #12218 #11850
Issue
s: #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
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment