Diffstat (limited to 'wiki/src/blueprint/SponsorS/reports/2016_05.mdwn')
1 files changed, 58 insertions, 36 deletions
diff --git a/wiki/src/blueprint/SponsorS/reports/2016_05.mdwn b/wiki/src/blueprint/SponsorS/reports/2016_05.mdwn
index 631b368..0577698 100644
@@ -32,13 +32,41 @@ Everything in this report is public.
# B. Improve our quality assurance process
+## B.3. Extend the coverage of our test suite
+### B.3.11. Fix newly identified issues to make our test suite more robust and faster
+- Robustness improvements
+ The work that we did over the last two months on Chutney ([[!tails_ticket
+ 9521]]), for Tor simulation, and Dogtail ([[!tails_ticket 10721]]), for
+ automated interaction with graphical interfaces, has started to pay off.
+ Since mid-April, over 60 scenarios have been made reliable and enabled in our
+ main development branch. The vast majority of these scenarios comes from
+ Chutney, for Tor simulation, as we could reuse the existing tests without
+ modification, except in a few edge cases. Now, most of the problems that with
+ had related to transient network issues are solved.
+ For the end of this project, we will focus on Dogtail to solve glitches when
+ interacting with graphical user interfaces. This requires rewriting the
+ problematic parts of tests under a completely different paradigm.
+### B.3.14. Write tests for incremental upgrades ([[!tails_ticket #6309]])
+ This test has been carefully designed in such a way that it can be
+ applied on *any* Tails version -- normally these upgrades can only
+ be applied to a specific Tails version. This was the main difficulty
+ in this work, and with that solved, the implementation is simple,
+ and will be finished in early June.
## B.4. Freezable APT repository
-The work we have done has been reviewed, merged into the main Tails
+The work we have done has been reviewed, merged into the our main
development branch, and successfully used while preparing Tails
-2.4~rc1. Unsurprisingly, we had to fix a couple small bugs that
-earlier testing had not discovered, but all in all we're very
-satisfied by how the whole thing work: it has been very solid and
+2.4~rc1. Unsurprisingly, we had to fix a couple of small bugs that
+earlier testing had not discovered, but all in all we are very
+satisfied with the results: it has been very solid and
performed pretty well so far. We are proud to point to the first ever
tagged snapshot, that contains only the set of packages needed for
building Tails 2.4~rc1, and the corresponding source code:
@@ -60,8 +88,7 @@ Now, let's dive into the details:
needed: the code and corresponding documentation were reviewed,
merged, and used in production, so this is completed.
- So we're happy to report that deliverable B.4.3 has been completed
- in May.
+ So we are happy to report that deliverable B.4.3 was completed in May.
- B.4.5. Implement processes and tools for importing and freezing those packages ([[!tails_ticket 6299]], [[!tails_ticket 6296]])
@@ -75,7 +102,7 @@ Now, let's dive into the details:
* Manage a very custom configuration for `apt-cacher-ng`: this was
reviewed, merged, and used in production since then.
- * Manage `reprepro`'s database growth: we checked the actual data
+ * Manage the growth of the database of `reprepro`: we checked the actual data
in our production environment and realized that there is actually
no problem to be solved here; since we have enabled garbage
collection, the database has not grown at all.
@@ -83,7 +110,7 @@ Now, let's dive into the details:
- Miscellaneous follow-ups
We have submitted upstream three branches that improve the Puppet
- module we use to manage `reprepro` in ways that made it compatible
+ module that we use to manage `reprepro` in ways that made it compatible
with the needs of our freezable APT repository.
By the end of July, we will also do some polishing in various areas:
@@ -102,35 +129,32 @@ Now, let's dive into the details:
## C.1. Change in depth the infrastructure of our pool of mirrors
-XXX: u, please review
-The new mirror pool is now used by Tails Upgrader, by users who
-download Tails without using our Download And Verification Extension
-for Firefox (aka. DAVE), for any download that is not supported by
-DAVE (e.g. release candidates), and for downloads started from a web
-cases of this work are covered already, and only the "downloading with
-DAVE" use case is left to complete.
+The new mirror pool is now used by *Tails Upgrader* and the downloads from our
+website that are not supported by our *Download And Verification Extension*
+in the browser. We still have to make DAVE use the new pool of mirrors.
- C.1.2. Write & audit the code that makes the redirection decision from our website ([[!tails_ticket 8639]], [[!tails_ticket 8640]], [[!tails_ticket 11109]])
* `mirror-dispatcher.js`: we are still waiting for the auditor to do
a final security review.
- * Download And Verification Extension for Firefox: we have made some
- progress on the implementation, and coordinated with the person
- who will do the code review to ensure he will be available when we
- need it. XXX: u, please update/complete this part.
+ * Download And Verification Extension (DAVE) for Firefox: we have made great
+ progress. However,
+ we still need to ensure that, once a mirror is deleted, DAVE will be able to
+ resume a download that was started from another mirror.
+ We coordinated with the person who will do the code review to ensure
+ he will be available when needed.
- C.1.4. Communicate with each mirror operator to adapt their configuration ([[!tails_ticket 8635]], [[!tails_ticket 11079]])
This deliverable is completed:
- * All mirrors have now implemented the changes we requested.
+ * All mirrors have implemented the requested changes.
- * We have sent a call for mirrors to a number of fast mirror
- operators, and we already have 7 more mirrors. We will pursue this
- effort in June, even though we have already reached the goals we
+ * We sent a call for help to a number of fast mirror
+ operators and already have 7 more mirrors. We will pursue this
+ effort in June, even though we already reached the goals we
had set: we expected to have at least 30 mirrors in the pool once
the new infrastructure was ready, and 35 mirrors 3 months later,
and we already have 36 active mirrors as of May 31.
@@ -145,20 +169,18 @@ DAVE" use case is left to complete.
- C.1.7. Adjust update-description files for incremental upgrades ([[!tails_ticket 11123]])
We have adjusted the code of Tails Upgrader to use the new mirror
- pool. This code has been merged, and is now used by Tails Upgrader
+ pool. This code has been merged and is now used by Tails Upgrader
in production (starting with Tails 2.4~rc1), so this deliverable is
completed as well.
-- C.1.8. Clean up the remainers of the old mirror pool setup ([[!tails_ticket 8643]], [[!tails_ticket 11284]])
+- C.1.8. Clean up the remainders of the old mirror pool setup ([[!tails_ticket 8643]], [[!tails_ticket 11284]])
This is now only blocked by the work that is in progress on DAVE
## C.4. Maintain our already existing services
-XXX: bertagaz, please review/complete
-- C.4.6. Administer our services upto milestone VI
+- C.4.6. Administer our services up to milestone VI
We kept on answering the requests from the community and taking care
of security updates.
@@ -168,22 +190,22 @@ XXX: bertagaz, please review/complete
request to the Puppet module we use to manage… Puppet itself
- We noticed that our four newest virtual machines used to
+ We noticed that the four newest virtual machines which
continuously run our automated test suite on all ISO images built by
our Jenkins instance (B.2) did not reboot as intended between test
- suite runs. We investigated the root cause of the problem, and fixed
+ suite runs. We investigated the root cause of the problem and fixed
it ([[!tails_ticket 11467]]).
- We ported everything that made sense to, in our Puppet
- infrastructure, to use [Hiera](https://github.com/puppetlabs/hiera).
+ We ported different elements of our Puppet infrastructure
+ to use [Hiera](https://github.com/puppetlabs/hiera).
Not only this simplified a lot how we manage systems, but more
importantly, this allowed us to release quite a bit more of our
Puppet code. This is part of our strategy to treat infrastructure as
- code, and to enable more people to contribute to it without needing
+ code and to enable more people to contribute to it without needing
any special credentials.
We streamlined email reporting from failed cronjobs across our
- infrastructure, to ensure we don't miss problems.
+ infrastructure, to ensure we get all notifications.
We did lots of refactoring and miscellaneous clean ups in our Puppet
code. Sprint cleaning!