Commit f5c39860 authored by sajolida's avatar sajolida

Merge remote-tracking branch 'origin/master' into web/14559-permanent-incentive

parents 588d9a51 9f7931e4
http://torbrowser-archive.tails.boum.org/8.0.7-build3/
http://torbrowser-archive.tails.boum.org/8.0.8-build1/
ca18208ec388ede9dca348d94cd4805c605b7fbe8ff09a6f09346f4f36b587d4 tor-browser-linux64-8.0.7_ar.tar.xz
38ce192c9c608d123c490e25d18081c4b79517055e1359f24a09221cb318e340 tor-browser-linux64-8.0.7_ca.tar.xz
387d13665f96cf84742afa90e37589f424bcb211b650dc5f2d5983a0cf39204b tor-browser-linux64-8.0.7_da.tar.xz
aae6170a5629a26b48c054a6005b66544e67d59e1755aea19a5db7d3b5cc4ed9 tor-browser-linux64-8.0.7_de.tar.xz
bebe0f457f26723687073704ab4b072b696928dccdc1c73ff42d22f2688432e7 tor-browser-linux64-8.0.7_en-US.tar.xz
599e689bf94b9dc139444a4a81756cac05c25722c8ca5607d496063d02f19cf5 tor-browser-linux64-8.0.7_es-ES.tar.xz
70cf462e9b47f9df4d5bd1488820b4baaf5d60953a6f5ecaad5be290e3c0be77 tor-browser-linux64-8.0.7_fa.tar.xz
a6ff3036fa5d72ce6e63b751df28fa6342adfd98199ff9d2971881c8e8702d7b tor-browser-linux64-8.0.7_fr.tar.xz
88154a65257662cdf808073e5060459eac4f8f4354fb8a3c23c491e63e3971e5 tor-browser-linux64-8.0.7_ga-IE.tar.xz
edc358fa2992c4c1b7c9eaae21d9af23dfd7905925994782b305aba6c2e4e24d tor-browser-linux64-8.0.7_he.tar.xz
f3576c3987e178a0f6f86e69b57c3af0664b29e1b2eb0fe13fbaec65c85eb3f9 tor-browser-linux64-8.0.7_id.tar.xz
7a336b903e25e901b98d0c69cddec002d1a30130586542190890a17841e4df12 tor-browser-linux64-8.0.7_is.tar.xz
0a7534e676724799fdd3d460e8dc3fb9058c3b22c35f062ea573524873f38de3 tor-browser-linux64-8.0.7_it.tar.xz
6b100256672a51bc67b3c1163d42a3891c17d3bcb601d306d3439a6331bcdaa1 tor-browser-linux64-8.0.7_ja.tar.xz
928b9f835838bce822e07adfe40fb88811db68e6b020c9b58e1d55fa386f9a35 tor-browser-linux64-8.0.7_ko.tar.xz
7fd87d8e173cb8a9473a143e47c88096d69266b514c2dfc07dcc8bab4fb2d16d tor-browser-linux64-8.0.7_nb-NO.tar.xz
db55ea1acd9d7d39903c092241049d4bd5de138bd939d786844a1eda34b582c4 tor-browser-linux64-8.0.7_nl.tar.xz
e66d1c534b038a4bfe1dc7bff88a8a17bd6734f391187d926cbe0fcf3cb9b05a tor-browser-linux64-8.0.7_pl.tar.xz
3a51f831e6c0fc89fa33ea463920c974bf694da8aa0ec02201d9d8a01b51e26c tor-browser-linux64-8.0.7_pt-BR.tar.xz
843e9c3c67bc623cb0d0470fa88dbbe2c67460de641bebbd641f4e727a64eb67 tor-browser-linux64-8.0.7_ru.tar.xz
636c9cb14f632a03f073adef207b030f11c34e5f4254f756b95acd318defb38b tor-browser-linux64-8.0.7_sv-SE.tar.xz
a84f3710d293a240235460132b24f9bd514ccc9f483dd101c1258404357dc5fd tor-browser-linux64-8.0.7_tr.tar.xz
36c34cf23fd137c2bf445529cdfa5a7b2ed98873313c6f9e26342922b8b3b53d tor-browser-linux64-8.0.7_vi.tar.xz
ad5c782529f746050455916612a30b39c3acd0f77dace259401ed585f588f8d2 tor-browser-linux64-8.0.7_zh-CN.tar.xz
ba5a00e4bfe40de90c3c2be170367abaa45b86df0fab88cb966ba3bc37efe070 tor-browser-linux64-8.0.7_zh-TW.tar.xz
827381c6265029e90bbe0510a3805ded275fa43a6c1e9a70ad6b573954cf8b07 tor-browser-linux64-8.0.8_ar.tar.xz
a22fdb04003f0101915bfecd00326b11e5114041c1447b25d5691ec4db940c64 tor-browser-linux64-8.0.8_ca.tar.xz
a482769c70e35206b9a82f0ac03b3c24d741055d6e3bb8af19cf80168e4fd043 tor-browser-linux64-8.0.8_da.tar.xz
13f6d439dbc1c612bc2a03849b0fcc0e861629b33ccf4bbdcc8a8d2fb32716c1 tor-browser-linux64-8.0.8_de.tar.xz
b16b80a858dd28f254b2f748324b632fef7ebe8331a2d46c67016c1f1d5c9391 tor-browser-linux64-8.0.8_en-US.tar.xz
1d736ab404b1080d7820195230534f1e4ea802b4f8d114c02c1b614df5e1fab2 tor-browser-linux64-8.0.8_es-ES.tar.xz
a3136cbf990476114ae74f16d42c2a159f18032e94f172bdef75f9af7ffba8cf tor-browser-linux64-8.0.8_fa.tar.xz
0f90c194b30ad354f28cdb1993206ba45c8fdd6a3c698bb349a84efb07053bf9 tor-browser-linux64-8.0.8_fr.tar.xz
0322b4f824acfbb9b9b12aa466ffaedafe452c6e047d2023ec30d178676c02eb tor-browser-linux64-8.0.8_ga-IE.tar.xz
5cbe242b770d6c7ac7a8ed6139ebcb8fb1467a79d5f4910b0022044b71fa9f36 tor-browser-linux64-8.0.8_he.tar.xz
7774cd4c54ea64376a1dd126399784e8a5b466fa054851a554a1c2e8de731c02 tor-browser-linux64-8.0.8_id.tar.xz
6ecbea10450e57255e9a94a150b61e2fd7d70d225f52be4c117bdd1d2e3c6052 tor-browser-linux64-8.0.8_is.tar.xz
a9027f09b3c251bc7a80b90071f2b96860e9acdff773cf31f275e760ab17006d tor-browser-linux64-8.0.8_it.tar.xz
bebffb31e66fee4bd7b84af9863fbf23990d3c88021703fcedd1ad38e203b348 tor-browser-linux64-8.0.8_ja.tar.xz
c746ad231274011adb909c6b168ff4007d4964d8eec1ef23d2310f4b5996f207 tor-browser-linux64-8.0.8_ko.tar.xz
d6a160ebe8fa448d768022b02c7a8bbfdc5de55787fd3eab99adf275dd79c9ff tor-browser-linux64-8.0.8_nb-NO.tar.xz
93a306495215e8c2f70dd2d06ff09197c88926e4ac3a043ca1253a8999c0ffb0 tor-browser-linux64-8.0.8_nl.tar.xz
8ffef293214e770f96907429145bb7daa2cb01e0a4b14c67e58f5e072d268fb5 tor-browser-linux64-8.0.8_pl.tar.xz
3a3816c9069983576b4d1c3f8371315f89a55a7f37a00af572b3e790208c47a4 tor-browser-linux64-8.0.8_pt-BR.tar.xz
a0fa85ea83c65bb999c5351c59c97f6f40af933b51fde5b882ef9e264ed322c5 tor-browser-linux64-8.0.8_ru.tar.xz
d27af9f27823a4a9a93d762eea036e104af599a642af99aa962dc31f2a7b308f tor-browser-linux64-8.0.8_sv-SE.tar.xz
f32c98481fff6cdbed9db9ad623532f4c2a1417399c1da852b92e301b78efb0e tor-browser-linux64-8.0.8_tr.tar.xz
a7a64668a3cc083f517df75636594baded35d590716a417af295b2a8b147fab2 tor-browser-linux64-8.0.8_vi.tar.xz
fa5e6e8d1dfe580a639463a2240286b110eb8f1684ade467d2e8ca384746a70e tor-browser-linux64-8.0.8_zh-CN.tar.xz
d28190b1a802b1e75105302866c4b2d8d03eed9c9c4c93b85ac5fe63e06782d7 tor-browser-linux64-8.0.8_zh-TW.tar.xz
tails (3.13.1) unstable; urgency=medium
* Security fixes
- Upgrade Tor Browser to 8.0.8 (Closes: #16606, MFSA-2019-10).
- Upgrade NTFS-3G to 1:2016.2.22AR.1+dfsg-1+deb9u1 (DSA-4413-1).
-- Tails developers <tails@boum.org> Fri, 22 Mar 2019 20:54:03 +0000
tails (3.13) unstable; urgency=medium
* Major changes
......
This diff is collapsed.
......@@ -11,7 +11,13 @@ enabled, without the user having to do _anything_ special about it.
Means: use the shim signed by Microsoft + GRUB2.
We don't support booting on a custom built kernel, so that should be
relatively easy.
relatively easy. Except:
* The kernel won't allow loading an unsigned `aufs` module so we need
to migrate to `overlayfs` ([[!tails_ticket 8415]]).
* `overlayfs` does not allow stacking enough layers for our current
upgrade system, so we need to [[!tails_ticket 15281 desc="stack one
single SquashFS diff when upgrading"]].
Resources
=========
......@@ -46,5 +52,16 @@ Resources
by Greg Kroah-Hartman
* Linux Foundation's
[Making UEFI Secure Boot Work With Open Platforms](http://linuxfoundation.org/publications/making-uefi-secure-boot-work-with-open-platforms)
Automated testing
=================
* The hard(est) part seems to be about how to enroll the signing keys
into the nvram file. One option is to use `EnrollDefaultKeys.efi`
from OVMF.
* [Automating Secure Boot Testing](https://www.youtube.com/watch?v=qtyRR-KbXYQ):
how Red Hat does CI for Secure Boot (FOSDEM 2018)
* <https://wiki.ubuntu.com/UEFI/SecureBoot/Testing>
* <https://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm>
* <https://fedoraproject.org/wiki/Using_UEFI_with_QEMU#Testing_Secureboot_in_a_VM>
* <https://github.com/puiterwijk/qemu-ovmf-secureboot>
......@@ -7,6 +7,33 @@ Corresponding ticket: [[!tails_ticket 14567]]
currently being updated, the old version is still available
[here](https://www.eff.org/node/82654)).
## Use cases
### Signal for attorneys
People we met at the IFF 2019 started experimenting with using Signal as
point of contact for attorneys and their clients or whistle-blowing
sources.
They have a script that makes it possible to validate a land-line phone
at the attorney's office to create a Signal account attached to it. This
Signal account can then be used from Signal on a desktop computer, or
even better, on Tails.
This setup has several advantages:
- Giving your office telephone to a client doesn't look as dodgy as
sharing your personal mobile phone number.
- Attorneys are obliged to have a land-line phone as their official
point of contact.
- Attorneys can keep their work and personal contacts separate.
- Attorneys can attend their work Signal even when outside of office and
keep secure communications with their clients even when traveling.
An important limitation for this to work is that you can't change the
name of contacts that were added, using a phone number, to Signal
desktop. There is a feature request for this upstream.
## General requirements
**MUST**
......
......@@ -19,14 +19,14 @@ beginning of May.
- December 2018: spriver
- January 2019: emmapeel
- February 2019: intrigeri
- March 2019: TheNerdyAnarchist
- April 2019:
- May 2019:
- March 2019: sajolida
- April 2019: TheNerdyAnarchist & emmapeel
- May 2019: u
- June 2019:
- July 2019: u
- July 2019:
- August 2019: intrigeri
- September 2019:
- October 2019:
- October 2019: u
- November 2019:
- December 2019:
......
[[!meta title="Tails report for March, 2019"]]
[[!meta date="`date --rfc-2822` eg. Thu, 08 Feb 2018 07:21:15 +0000"]]
[[!pagetemplate template="news.tmpl"]]
[[!toc ]]
Releases
========
* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|bugfix|emergency] release).
* Tails VERSION+1 is [[scheduled for MONTH DAY|contribute/calendar]].
The following changes were introduced in Tails VERSION:
XXX: Copy the "Changes" section of the release notes, and compact a bit:
* Remove lines about software upgrade (that's not Tails itself).
* Remove screenshots.
* Remove "New features" and "Upgrades and changes" headlines.
* Remove line about Changelog.
Code
====
XXX: If you feel like it and developers, foundation team, and RMs don't do it themselves,
list important code work that is not covered already by the
Release section (for example, the changes being worked on for
the next version).
Documentation and website
=========================
XXX: If you feel like it and technical writers don't do it
themselves, explore the Git history:
git log --patch --since='1 October' --until='1 November' origin/master -- "*.*m*"
User experience
===============
XXX: If you feel like it and the UX team does not do it
themselves, check the archives of tails-ux:
<https://lists.autistici.org/list/tails-XXX.html>
Hot topics on our help desk
===========================
XXX: Ask tails-bugs@boum.org to list hot topics for the last month.
1.
1.
1.
Infrastructure
==============
Funding
=======
XXX: The fundraising team should look at the fundraising Git.
git log --patch --since='1 December' --until='1 January' origin/master
XXX: The fundraising and accounting teams should look at the archives of <tails-fundraising@boum.org> and <tails-accounting@boum.org>.
Outreach
========
- We stopped having public monthly meetings in favor of internal standup
meetings.
Past events
-----------
Upcoming events
---------------
- sajolida and emmapeel will be at the [Internet Freedom
Festival](https://internetfreedomfestival.org/) on April 1&ndash;5 in
Valencia, Spain.
sajolida will hold there a workshop on [Creating
usable tools from day one with paper
prototyping](https://platform.internetfreedomfestival.org/en/IFF2019/public/schedule/custom/975).
On-going discussions
====================
XXX: Link to the thread on <https://lists.autistici.org/list/tails-XXX.html>.
Press and testimonials
======================
XXX: Copy content from press/media_appearances_2019.mdwn
This page is continuously updated by tails-press@boum.org, so if
it's empty there might be nothing special to report.
Translations
============
XXX: Add the output of (adjust month!):
sudo apt-get install intltool
git checkout $(git rev-list -n 1 --before="September 1" origin/master) && \
git submodule update --init && \
./wiki/src/contribute/l10n_tricks/language_statistics.sh
Metrics
=======
* Tails has been started more than BOOTS/MONTH times this month. This makes BOOTS/DAY boots a day on average.
* SIGS downloads of the OpenPGP signature of a Tails USB image or ISO from our website.
* WHISPERBACK bug reports were received through WhisperBack.
[[How do we know this?|support/faq#boot_statistics]]
XXX: Ask <tails@boum.org> for these numbers.
......@@ -72,6 +72,11 @@ Outreach
Past events
-----------
- [carlosm2](https://twitter.com/dospesosinc) held 2 workshops about Tails in Mexico:
- On [April 13](https://twitter.com/dospesosinc/status/1115675448753573888) at the Colima Hacklab
- On [April 25](https://flisol.acatlan.unam.mx/) at UNAM, Ciudad de Mexico
Upcoming events
---------------
......
* This suppose you have either a sid/experimental system with latest GNOME packages or a pbuilder experimental setup.
* In a VM, enable experimental sources then:
apt-get build-dep -t experimental gnome-shell
apt-get install quilt git-buildpackage
* For pbuilder:
pbuilder create --distribution experimental --override-config
* clone debian git in gnome-shell-debian
git clone https://salsa.debian.org/gnome-team/gnome-shell.git gnome-shell-debian
* create upstream/latest branch
git co -b upstream/latest origin/upstream/latest
* clone upstream git
git clone https://gitlab.gnome.org/GNOME/gnome-shell.git gnome-shell-git
git submodule update --init
* disable upstream VCS tag checking
commit 3f53de522495a321bb962e5b9e4ddaca66957823
Author: user <user@debian>
Date: Tue Apr 2 16:31:22 2019 +0200
disable upstream VCS tag checking
diff --git a/debian/gbp.conf b/debian/gbp.conf
index b24011a15..904e0e5d0 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -2,7 +2,7 @@
pristine-tar = True
debian-branch = debian/master
upstream-branch = upstream/latest
-upstream-vcs-tag = %(version)s
+#upstream-vcs-tag = %(version)s
[buildpackage]
sign-tags = True
* import upstream repository
gbp import-orig --verbose --upstream-version=3.33.0-4 --filter=.git --filter=.gitignore ~/Documents/gnome-shell-git/
^
increase this at each build
* disable all patches
commit 31962cfec99808e57404a970c59202c8e40c1c76 (HEAD -> debian/master)
Author: user <user@debian>
Date: Tue Apr 2 16:38:27 2019 +0200
disable all debian specific patches
diff --git a/debian/patches/series b/debian/patches/series
index 2e1f1ebb9..e69de29bb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,8 +0,0 @@
-userWidget-Fix-avatar-size.patch
-layout-Use-custom-actor-for-uiGroup.patch
-texture-cache-Apply-resource-scale-to-the-right-dimension.patch
-theme-improve-legibility-of-error-messages.patch
-st-widget-Add-missing-g_return_val_if_fail.patch
-st-theme-node-transition-Exclude-get_new_paint_state-from.patch
-magnifier-Fix-color-argument.patch
-tweener-Save-handlers-on-target-and-remove-them-on-destro.patch
* build
gbp buildpackage
or with pbuilder:
BUILDER=pbuilder gbp buildpackage --git-pbuilder --git-dist=experimental --git-arch=amd64 -nc
* install
sudo dpkg -i ../gnome-shell_3.33.0-4-1_amd64.deb ../gnome-shell-common_3.33.0-4-1_all.deb
......@@ -209,29 +209,39 @@ When a Git *main* branch (`devel`, `testing`, `stable`,
`feature/jessie`) is merged into another *main* branch, the corresponding
operation must be done on the APT suites.
0. Set some environment variables:
WORKDIR=$(mktemp -d)
# the branch you want to merge
SRC=stable
# the branch you want to merge _into_
DST=devel
1. Save the list of packages currently present in the APT suite we
want to merge *into*, e.g. `reprepro list devel`.
want to merge *into*:
ssh reprepro@incoming.deb.tails.boum.org \
reprepro list "$DST" \
> "$WORKDIR/$DST.orig.list"
2. Make sure you are not going to overwrite newer packages with
older ones (hint: use the `tails-diff-suites` script).
older ones:
3. Merge the APT suites:
ssh reprepro@incoming.deb.tails.boum.org \
tails-diff-suites "$SRC" "$DST"
1. Set some environment variables:
… and look for packages that are newer in `$DST` than in `$SRC`.
# the branch you want to merge
SRC=stable
# the branch you want to merge _into_
DST=devel
3. Merge the APT suites:
2. Merge in Git and APT:
1. Merge in Git and APT:
git checkout "$DST" && \
git merge "$SRC" && \
ssh reprepro@incoming.deb.tails.boum.org \
tails-merge-suite "$SRC" "$DST"
3. Restore the `config/base_branch` if needed:
2. Restore the `config/base_branch` if needed:
echo "${DST}" > config/base_branch && \
git commit config/base_branch -m "Restore ${DST}'s base branch." || :
......
......@@ -4,20 +4,17 @@ All times are referenced to Berlin and Paris time.
## 2019Q1
* 2019-03-19: Test and **release Tails 3.13** (kibi is the RM)
* 2019-03-20 to 2019-03-22: [[!wikipedia Pwn2Own]], which often triggers an emergency Firefox release
* 2019-04-02 to 2019-04-05: [[Foundations Team|contribute/working_together/roles/foundations_team]] sprint
- Port Tails to Debian 10 (Buster)
* 2019-05-06, 16:00: [[Foundations Team|contribute/working_together/roles/foundations_team]] meeting
- [smallish UX improvements](https://redmine.tails.boum.org/code/issues/14544#note-75)
* 2019-05-14: **Release 3.14** (Firefox 60.7, Tor Browser 8.5; bugfix release — kibi is the RM)
* 2019-05-23 and 2019-05-24: Buster (remote) sprint
* 2019-06-03, 16:00: [[Foundations Team|contribute/working_together/roles/foundations_team]] meeting
* 2019-06-17 and 2019-06-18: Buster (remote) sprint
* 2019-06-25 to 2019-06-27: Translation platform sprint
* 2019-07-03, 16:00: [[Foundations Team|contribute/working_together/roles/foundations_team]] meeting
......@@ -32,7 +29,9 @@ All times are referenced to Berlin and Paris time.
* 2019-10-03, 16:00: [[Foundations Team|contribute/working_together/roles/foundations_team]] meeting
* 2019-10-22: **Release 3.17 or 4.0** (Firefox 68.2, major release)
* 2019-10-22: **Release 3.17** (Firefox 68.2, major release); this release might be
based on Debian Buster and then called 4.0, but for now Release Managers
should assume it's 3.17
* 2019-11-06, 16:00: [[Foundations Team|contribute/working_together/roles/foundations_team]] meeting
......
......@@ -1050,7 +1050,7 @@ Thunderbird itself leaks a lot of data and makes DNS requests, for example by
retrieving mail server configurations from a remote server over an insecure
channel. This is prevented by the TorBirdy extension as well as by custom
patches for Thunderbird in Tails, which we are currently in the process of
upstreaming ([[!tails_ticket 11215]]).
upstreaming ([[!tails_ticket 6156]]).
Thunderbird generates `Message-ID` headers using the hostname part of
the sender's email address, which does not leak usage of the PELD nor
......
......@@ -134,7 +134,7 @@ before being merged, it's better if you push your work to a dedicated
Git topic branch, and [[ask us to review it|contribute/merge policy/submit]]. If you already know where
to host your personal repository in a public online place, this is
great; otherwise, you can [fork us on
GitLab](https://gitlab.com/Tails/tails), or ask the Tails system
Salsa](https://salsa.debian.org/tails-team/tails), or ask the Tails system
administrators ([[tails-sysadmins@boum.org|about/contact#tails-sysadmins]]) to host your repository.
# Want more?
......
[[!meta title="Checklist for release notes"]]
- Create a branch based on the development branch for this release
- `web/nnnnn-x.y-release-notes`
- Fetch and checkout the `web/release-x.y` branch that was pushed
by the Release Manager
- Copy template from `contribute/how/documentation/release_notes/template.mdwn` to `news/version_x.y.mdwn`
- Replace placeholders in template
- Gather information about changes
......
......@@ -172,6 +172,12 @@ the progressive or perfect tense.
And not *graphics adapters*, *graphics*, *graphical hardware*, or
*video card*.
<a id="internet"></a>
- **Internet**
Capitalize. When used as a noun, always preceded by *the*.
<a id="media"></a>
- **media** and **installation media**
......@@ -216,6 +222,13 @@ the progressive or perfect tense.
The word *persistence* can be omitted if it is redundant from the context
(for example on [[doc/first_steps/persistence/configure]]).
<a id="please"></a>
- **please**
Avoid please except in situations where the user is asked to do
something inconvenient or the software is to blame for the situation.
<a id="procedures"></a>
- **procedures** (a series of steps)
......
......@@ -27,8 +27,8 @@ Resources
- [[Paper prototyping and *WireframeSketcher*|user_experience/paper_prototyping]]
- [[Survey platform (*LimeSurvey*)|user_experience/limesurvey]]
- [[Guidelines for user testing|user_experience/testing]]
- [[Recording user testing|user_experience/recording]]
- [[Guidelines for usability testing|user_experience/testing]]
- [[Recording usability testing|user_experience/recording]]
- [[Preparing video clips|user_experience/clip]]
- Participant Bill of Rights (adapted from
[Simply Secure](https://simplysecure.org/knowledge-base/)):
......@@ -37,7 +37,7 @@ Resources
- System Usability Scale (SUS) questionnaire:
- [English ODT](https://github.com/sajolida/tails-ux/raw/master/tools/SUS.en.fodt)
- [Spanish ODT](https://github.com/sajolida/tails-ux/raw/master/tools/SUS.es.fodt)
- Checklist for user testing:
- Checklist for usability testing:
- [English ODT](https://github.com/sajolida/tails-ux/raw/master/tools/user_testing_checklist.fodt)
- Rainbow table:
- [Template ODS](https://github.com/sajolida/tails-ux/raw/master/tools/rainbow_table.fods)
......
[[!meta title="Recording user testing"]]
[[!meta title="Recording usability testing"]]
[[!toc levels=2]]
<a id="camera"></a>
Recording with a camera using <span class="application">VLC</span>
==================================================================
......@@ -62,6 +64,8 @@ IPEVO](https://www.ipevo.com/) works fine from Tails.
- Specify a destination file under
<span class="filename">~/Persistent/</span>.
<a id="screencast"></a>
Recording a screencast
======================
......
[[!meta title="Guidelines for user testing"]]
[[!meta title="Guidelines for usability testing"]]
User testing is an irreplaceable tool to understand user experience and
Usability testing is an irreplaceable tool to understand user experience and
take decisions while doing design iterations. Here are a few guidelines
to take the most of it.
......
[[!meta title="Git merge policy: review and merge process"]]
<a id="review"></a>
## Review
- When you start doing a review'n'merge, assign the relevant ticket to
you, in order to avoid duplicated work.
- When you start doing a review'n'merge, assign the relevant ticket
and merge request to you, in order to avoid duplicated work.
- Merge the base branch (the one you're supposed to merge the reviewed
topic branch into, as specified in `config/base_branch` and in the
pull request -- they must match) into the topic branch.
......@@ -24,6 +26,10 @@
maintenance includes: polishing the proposed changes to make them fit
for release; writing and updating the design and end-user
documentations; fixing bugs.
- 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.
- Remember that it's hard to receive negative feedback. Don't forget
to note the good parts, be constructive and precise in your
comments, and never use reviews to make personal attacks. You can
......@@ -31,8 +37,18 @@
- [Kate Heddleston: Criticism and ineffective feedback](https://www.kateheddleston.com/blog/criticism-and-ineffective-feedback) (blog post on how to do a good review)
- [Liane Davey: Maybe you shouldn't give feedback](http://www.3coze.com/2016/07/17/bite-your-tongue/)
<a id="merge"></a>
## Merge
<div class="note">
If the proposed change was submitted as a merge request on <a
href="https://salsa.debian.org/tails-team/tails">Salsa</a>, don't
click <i>Merge</i> there: while we can use GitLab for reviews, our
infrastructure is not ready to consume merge operations done there, so
you need to merge on the command line.
</div>
Merge the branch with `--no-ff`:
- for a new feature: into `devel`
......
......@@ -5,30 +5,38 @@ be named `feature/XXX`. For a bugfix about YYY, it should be named
`bugfix/YYY`. Ideally, include the relevant ticket number in the topic
branch name, e.g. `bugfix/7173-upgrade-syslinux`.
When the developer thinks it is good enough and has tested it, she must:
When you think it is good enough and have tested it, you have to:
- Set the ticket's *Status* field to *In Progress* (if you do not see
this field when editing the ticket, ask the [[sysadmin team|contribute/working_together/roles/sysadmins]]
to grant you the necessary permissions).
- Point the ticket's *Feature Branch* field to your branch.
- Set the ticket's *Target version* field to the release you would
like your changes to be in.
- If you have access to our Jenkins instance (if you don't know what
this means, you do not) please make sure that your branch has not
broken any tests! Or, if you only want a first review of your code,
without bothering with the build & test status on Jenkins, that's fine:
make it clear to the reviewer that it's what you expect and that
your branch is not ready to merge.
- 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 nobody on the
[[Foundations Team|working_together/roles/foundations_team]] will 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.
- For important changes, if you feel the need to ask input from the
greater development community, notify the [[tails-dev@boum.org|about/contact#tails-dev]]
mailing list.
1. Push your branch
- If you have commit access to the official Tails Git repository,
push your branch there so our CI picks it up.
- Else, push to your personal Git repository:
[fork us on Salsa](https://salsa.debian.org/tails-team/tails).
2. Set the ticket's *Status* field to *In Progress* (if you do not see
this field when editing the ticket, ask the [[sysadmin team|contribute/working_together/roles/sysadmins]]
to grant you the necessary permissions).
3. Point the ticket's *Feature Branch* field either to your branch
or to a merge request on [Salsa](https://salsa.debian.org/tails-team/tails).
4. Set the ticket's *Target version* field to the release you would
like your changes to be in.
5. Make it clear what you're requesting: merging? some advice? an initial
code review of work that's not finished yet?
6. If you have access to our Jenkins instance and you are requesting a merge:
- Ensure your branch builds on Jenkins.
- 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*.
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.
- Else, assign the ticket to nobody, i.e. unassign it from yourself.
The [[Foundations Team|working_together/roles/foundations_team]]
will either handle the review themselves or help you find a suitable
reviewer.
8. For important changes, if you feel the need to ask input from the
greater development community, notify the [[tails-dev@boum.org|about/contact#tails-dev]]
mailing list.
Then, if the [[reviewer|contribute/merge_policy/review]] asks for more
development to be done before
......@@ -37,3 +45,8 @@ more dev* or *Needs more info* state, and
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
the reviewer are fixed.
The reviewer is 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. They must
report back about these changes on the ticket.
This diff is collapsed.