summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/src/blueprint')
-rw-r--r--wiki/src/blueprint/HTTP_mirror_pool.mdwn18
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2015_09.mdwn296
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2015_10.mdwn2
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2015_11.mdwn2
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2015_12.mdwn2
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2016_01.mdwn2
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2016_02.mdwn2
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2016_03.mdwn2
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2016_04.mdwn2
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2016_05.mdwn2
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2016_06.mdwn2
-rw-r--r--wiki/src/blueprint/SponsorS/reports/2016_07.mdwn2
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/automated_tests_specs.mdwn21
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/jenkins.mdwn271
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/resources.mdwn140
-rw-r--r--wiki/src/blueprint/l10n_Italian.mdwn58
-rw-r--r--wiki/src/blueprint/monthly_meeting.mdwn4
-rw-r--r--wiki/src/blueprint/report_2015_08.mdwn36
18 files changed, 590 insertions, 274 deletions
diff --git a/wiki/src/blueprint/HTTP_mirror_pool.mdwn b/wiki/src/blueprint/HTTP_mirror_pool.mdwn
index 36d2516..6a5fafd 100644
--- a/wiki/src/blueprint/HTTP_mirror_pool.mdwn
+++ b/wiki/src/blueprint/HTTP_mirror_pool.mdwn
@@ -1,14 +1,5 @@
**Ticket**: [[!tails_ticket 7161]]
-The idea I had was to let the server(s) send a reduced list of hosts. Not
-only it would allow to work-around Tor DNS limitations, but also to have
-some weighted round robin, in order to prioritize some high bandwidth
-mirrors, if we choose to.
-
-If I had to mention the ideal design goals for such changes, I would say
-that the more straightforward would be the better for implementation and
-also for maintainability.
-
[[!toc levels=3]]
# The plan
@@ -42,6 +33,15 @@ We decided to implement a two-way strategy for this feature:
# Initial research
+The idea I had was to let the server(s) send a reduced list of hosts. Not
+only it would allow to work-around Tor DNS limitations, but also to have
+some weighted round robin, in order to prioritize some high bandwidth
+mirrors, if we choose to.
+
+If I had to mention the ideal design goals for such changes, I would say
+that the more straightforward would be the better for implementation and
+also for maintainability.
+
## Using DNS
Using DNS seems to be an easy way to do some round robin in low level. It
diff --git a/wiki/src/blueprint/SponsorS/reports/2015_09.mdwn b/wiki/src/blueprint/SponsorS/reports/2015_09.mdwn
index d47aecb..315503b 100644
--- a/wiki/src/blueprint/SponsorS/reports/2015_09.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2015_09.mdwn
@@ -14,28 +14,308 @@ This reports covers the activity of Tails in September 2015.
Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
-tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+tracker which contain more technical details and timeline. For example,
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
-## A.n. description of subsection
+- A.1.3. Integrate Icedove into Tails
-- A.n.m. description of deliverable: ticket numbers
+ We amended the strategy we had in mind initially and made it more
+ incremental. If time allows, a first stage will be to include
+ Icedove in Tails 1.7 (2015-11-03), but without the Icedove account
+ setup wizard. During this first stage, Torbirdy's own account setup
+ wizard will be used. And the second stage will be about securing
+ Icedove's wizard (#6154). If this works out as we hope, Tails users
+ will be able to start using Icedove two months earlier than what we
+ planned initially, and the transition period from Claws Mail will be
+ longer, and thus smoother, for users.
- status summary:
+ We started implementing this plan (#10285), set up team coordination
+ tools, and triaged what is a blocker for the first stage, from what is
+ not.
- * what was done
- * what is the outcome (how it makes Tails better)
- * what was not done, and why
+ Then we worked on the "Torbirdy uses Arabic as a default locale"
+ bug, submitted a pull request upstream, that was accepted (#9821).
+
+- A.1.4. Provide a migration path for our users from Claws Mail to Icedove
+
+ We decided how long to keep Claws Mails once we have Icedove
+ (#10010), and initiated work on the migration for users of Tails
+ persistence feature (#9498).
# B. Improve our quality assurance process
+## B.2. Continuously run our entire test suite on all those ISO images once they are built
+
+- B.2.1. Adjust our infrastructure to run tests in parallel
+
+ Great progress was made on this front, and more specifically on the
+ last remaining chunk of it: firing up a clean test runner virtual
+ machine before each test suite run. It was tricky to implement this in
+ a way that prevented race conditions, but we now have a working
+ prototype that we are confident fixes the issues we have seen earlier
+ (#9486, #10215). Along the way we encouraged a few Debian developers
+ to take care of a package we rely on (`jenkins-job-builder`), and one
+ of them promptly took it over and updated it to the version we need
+ (#9646).
+
+- B.2.2. Decide what kind of ISO images qualify for testing and when,
+ how to process, advertise, and store the results (#8667)
+
+ Early in September, we reached an agreement on all discussion topics
+ that were left pending in August, such as how to archive videos from
+ test suite runs. As can be seen in the "Help Jenkins integration"
+ section below, our test suite team promptly started adjusting their
+ code to match what we will need on the Jenkins deployment.
+
+ <https://tails.boum.org/blueprint/automated_builds_and_tests/automated_tests_specs/>
+
+- B.2.3. Research and design a solution to generate a set of Jenkins ISO test jobs
+
+ Some research and experiments were done for sending ISO images that
+ shall be tested to the test suite runner virtual machines (#9597), and
+ major blockers were removed in the underlying infrastructure. Some of
+ our Puppet code saw a nice refactoring in this process. On the same
+ topic, we reached a consensus regarding what "old" ISO image to use
+ for tests that require two images, such as upgrade tests (#10117). And
+ here as well, test suite developers promptly implemented what we
+ needed (#10147).
+
+ <https://tails.boum.org/blueprint/automated_builds_and_tests/jenkins/>
+
+## B.3 Extend the coverage of our test suite
+
+### General improvements
+
+- Filesystem shares are incompatible with QEMU snapshots: #5571
+
+ We have come up with a short-term strategy that will work well with
+ our current workflow. In addition we have our eyes on a long-term
+ technical solution that will require adding a small feature into
+ upstream QEMU. This is, however, out of the scope of this
+ deliverable.
+
+### Help Jenkins integration
+
+These changes, on the test suite side, were prompted by the ongoing
+work on "B.2. Continuously run our entire test suite on all those ISO
+images once they are built".
+
+It should be noted that many of the things mentioned here also greatly
+assist developers when debugging the automated test suite.
+
+- Leverage Cucumber's formatter system for debug logging: #9491
+
+ This makes it easier to have clean console logging while still
+ keeping the full debug log in a separate file. Consequently it will
+ be easier to get an overview of how a test is currently running.
+
+- Capture individual videos for failed scenarios only: #10148
+
+ This will both make these video artifacts more manageable and useful
+ for the developers (more focused, better granularity), and will save
+ a lot of disk space on our servers by excluding videos of tests that
+ succeeded and hence aren't very interesting.
+
+- Make the old Tails ISO default to the "new" ISO: #10147
+
+ This compromise will test 90% of what we want to test, and simplify
+ the Jenkins setup by eliminating the need to share multiple ISO
+ artifacts to the test suite context.
+
+### B.3.6. Fix newly identified issues to make our test suite more robust and faster
+
+#### Performance improvements
+
+- Snapshot improvements: #6094, #8008
+
+ The proof-of-concept that was written as part of B.3.4 has matured
+ into a reliable implementation and
+ it is basically done; only fine-tuning and style improvements
+ remain. It is expected to be ready for the Jenkins deployment in
+ Milestone III, and will allow us to run 33% more tests. It will add
+ less overhead for new tests using persistence in the future, and
+ thus complete "B.3.9. Optimize tests that need a persistent volume"
+ three months in advance.
+
+- Use the more efficient x264 encoding when capturing videos: #10001
+
+ This will reduce the CPU load on the host running the automated test
+ suite, as well as reduce its runtime with a few percent.
+
+- Optimize IRC test using waitAny: #9653
+
+ In case there are connection issues, this may save several minutes
+ per instance by waiting for both the failure and success condition
+ in parallel, instead of serially.
+
+#### Robustness improvements
+
+Some of what follows was part of a project we have with
+another sponsor.
+
+- Avoid nested FindFailed exceptions in waitAny()/findAny(): #9633
+
+ This works around a race condition due to a bug in Rjb that made
+ these helpers fail with some probability depending on the host
+ hardware.
+
+- Import logging module in otr-bot.py: #9375
+
+ Without this fix, the bot may occasionally fail due to it wanting to
+ use the logging facility when it is not in place.
+
+- Force new Tor circuit and reload web site on browser
+ timeouts: #10116
+
+ Given the inherent instability of Tor circuits, this will
+ drastically improve the robustness of all Tor Browser tests.
+
+- Pidgin's multi-window GUI sometimes causes unexpected behaviour
+ (e.g. one window covering the window we want to interact with):
+
+ * Focus Pidgin's buddy list before trying to access the tools
+ menu: #10217
+
+ * Wait for (and focus if necessary) Pidgin's Certificate windows: #10222
+
+- Develop a strategy for dealing with newly discovered fragile tests: #10288
+
+ By leveraging our Jenkins instance, following this strategy will
+ isolate individual robustness issues into individual branches while
+ keeping all other branches functional. Consequently it will be
+ easier to track and deal with future robustness issues.
+
+- Escape regexp used to match nick in CTCP replies: #10219
+
+ Due to how we randomize the nick name for the default Pidgin
+ accounts, there was a 10% chance to generate one with characters
+ that would have a special meaning when used inside regular
+ expressions, causing failures.
+
+### Writing more automated tests
+
+- B.3.8. Automatically test that udev-watchdog is monitoring the
+ right device: #9890.
+
+ This was completed and merged almost four months ahead of schedule.
# C. Scale our infrastructure
+## C.1. Change in depth the infrastructure of our pool of mirrors
+
+We started working on this project, and decided to handle the
+redirection on the client's side (for the record, the original plan
+was to do it server-side). We quickly put together a very rough
+proof-of-concept, and then moved on to update our plans for the next
+steps, accordingly to our new technological choice.
+
+The big picture is described on the corresponding blueprint:
+<https://tails.boum.org/blueprint/HTTP_mirror_pool/>
+
+- C.1.1. Specify a way of describing the pool of mirrors
+
+ We picked a serialization format (JSON) that matches our
+ implementation choices, and started researching what would be the
+ best naming scheme for mirrors, taking into account future HTTPS
+ hardening we have in mind, and support in various popular web
+ servers (#10294).
+
+- C.1.3. Design and implement the mirrors pool administration process and tools
+
+ We settled on ikiwiki overlays for integration into our website, and
+ on using Git and SSH to store and convey the configuration (#8637).
+
+- C.1.2. Write & audit the code that makes the redirection decision
+
+ We did some prototyping work (#8639), and then started refactoring
+ it so that the code can be reused by other components that will need
+ to implement the same redirection scheme client-side (#10284).
+
+## C.2. Be able to detect within hours failures and malfunction on our services
+
+This deliverable is technically due for January 15, but we kept on
+working on it.
+
+- C.2.1. Research and decide what monitoring solution to use: #8645
+
+ We completed experiments and comparisons between monitoring systems,
+ and settled on Icinga 2. We started looking for solutions regarding
+ the single requirement of ours that it does not satisfy.
+
+ <https://tails.boum.org/blueprint/monitor_servers/>
+
+- C.2.2. Set up the monitoring software and the underlying
+ infrastructure: #8646, #8647
+
+ We found hosting for our monitoring setup, got access to the
+ machine, and installed an operating system on it.
+
+## C.4. Maintain our already existing services
+
+This covers "C.4.3. Administer our services upto milestone III" until
+the end of September.
+
+Aside of the usual security updates and taking care of daily requests
+coming from the Tails development community, we did some resources
+planning, and updated the system requirements for the VM that will be
+used as a failover for our critical services (#10243) and looked for
+hosting that would meet our needs (#10244). We have an initial
+agreement with a hosting organization, and will follow-up on
+this shortly.
# D. Migration to Debian Jessie
+## D.1. Adjust to the change of desktop environment to GNOME Shell
+
+- D.1.1. Adjust to the change of desktop environment to GNOME Shell
+
+ We completed the work started on our "Shutdown helper" applet for
+ Jessie (#8302): visually impaired users can now use it, and we made
+ sure it is integrated with our translation system.
+
+ We cleaned up the desktop Applications menu (#8505).
+
+## D.6. Upgrade Tails-specific tools to Debian Jessie technologies
+
+- D.6.1. Port Tails-specific tools from udisks 1 to udisks 2
+
+ We followed up on the persistent volume assistant's porting to
+ udisks 2, and made sure it does not trigger spurious GNOME
+ notifications that could confuse users (#9280).
+
+- D.6.3. Port WhisperBack, our integrated bug reporting tool, to Python 3
+
+ Native SOCKS support was completed, which was the only missing piece
+ to make WhisperBack work great on Jessie and Python 3 (#9412).
+
+## Additional improvements that were not planned
+
+- When starting Tails in a virtual machine that runs with non-free
+ technology (and does not hide this fact), users are now warned about
+ the risks (#5315).
+
+- Simplify printers administration: it can now be done without having
+ to set an administration password, just like it was back when Tails
+ was based on Debian Squeeze (#8443). This removes a usability
+ pain-point, namely the need to restart Tails when one realizes too
+ late they need to print a document, and should have set an
+ administration password. In passing, we noticed that AppArmor
+ blocked adding a printer on Jessie, and fixed it (#10210).
# E. Release management
+
+- Tails 1.6 was released on 2015-09-22 [1]:
+
+ * Upgrade Tor Browser to version 5.0.3 (based on Firefox 38.3.0 ESR).
+ * Upgrade I2P to version 0.9.22 and enable its AppArmor profile.
+ * Fix several issues related to MAC address spoofing:
+ - If MAC address spoofing fails on a network interface and this
+ interface cannot be disabled, then all networking is now
+ completely disabled.
+ - A notification is displayed if MAC address spoofing causes
+ network issues, for example if a network only allows
+ connections from a list of authorized MAC addresses.
+
+ [1] <https://tails.boum.org/news/version_1.6/>
diff --git a/wiki/src/blueprint/SponsorS/reports/2015_10.mdwn b/wiki/src/blueprint/SponsorS/reports/2015_10.mdwn
index 00c9e5f..02e83cc 100644
--- a/wiki/src/blueprint/SponsorS/reports/2015_10.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2015_10.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
diff --git a/wiki/src/blueprint/SponsorS/reports/2015_11.mdwn b/wiki/src/blueprint/SponsorS/reports/2015_11.mdwn
index 0786212..641aea1 100644
--- a/wiki/src/blueprint/SponsorS/reports/2015_11.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2015_11.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
diff --git a/wiki/src/blueprint/SponsorS/reports/2015_12.mdwn b/wiki/src/blueprint/SponsorS/reports/2015_12.mdwn
index 78bc89a..2f0b005 100644
--- a/wiki/src/blueprint/SponsorS/reports/2015_12.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2015_12.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
diff --git a/wiki/src/blueprint/SponsorS/reports/2016_01.mdwn b/wiki/src/blueprint/SponsorS/reports/2016_01.mdwn
index 6f53f65..6ef80aa 100644
--- a/wiki/src/blueprint/SponsorS/reports/2016_01.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2016_01.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
diff --git a/wiki/src/blueprint/SponsorS/reports/2016_02.mdwn b/wiki/src/blueprint/SponsorS/reports/2016_02.mdwn
index 0f3a2f2..bae0400 100644
--- a/wiki/src/blueprint/SponsorS/reports/2016_02.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2016_02.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
diff --git a/wiki/src/blueprint/SponsorS/reports/2016_03.mdwn b/wiki/src/blueprint/SponsorS/reports/2016_03.mdwn
index 5ae6ea8..537075f 100644
--- a/wiki/src/blueprint/SponsorS/reports/2016_03.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2016_03.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
diff --git a/wiki/src/blueprint/SponsorS/reports/2016_04.mdwn b/wiki/src/blueprint/SponsorS/reports/2016_04.mdwn
index 6b576a0..cb781d7 100644
--- a/wiki/src/blueprint/SponsorS/reports/2016_04.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2016_04.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
diff --git a/wiki/src/blueprint/SponsorS/reports/2016_05.mdwn b/wiki/src/blueprint/SponsorS/reports/2016_05.mdwn
index a67279e..4b92d63 100644
--- a/wiki/src/blueprint/SponsorS/reports/2016_05.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2016_05.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
diff --git a/wiki/src/blueprint/SponsorS/reports/2016_06.mdwn b/wiki/src/blueprint/SponsorS/reports/2016_06.mdwn
index 3f90919..6ff6f7b 100644
--- a/wiki/src/blueprint/SponsorS/reports/2016_06.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2016_06.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
diff --git a/wiki/src/blueprint/SponsorS/reports/2016_07.mdwn b/wiki/src/blueprint/SponsorS/reports/2016_07.mdwn
index 8331a57..4f1bb0f 100644
--- a/wiki/src/blueprint/SponsorS/reports/2016_07.mdwn
+++ b/wiki/src/blueprint/SponsorS/reports/2016_07.mdwn
@@ -15,7 +15,7 @@ Everything in this report can be made public.
Note: the numbers preceded with a `#` correspond to tickets in our bug
tracker which contains more technical details and timeline. For example,
-ticket #6938 can been seed on https://labs.riseup.net/code/issues/6938.
+ticket #6938 can be seen on <https://labs.riseup.net/code/issues/6938>.
# A. Replace Claws Mail with Icedove
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 b694e6a..5df035b 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
@@ -128,26 +128,19 @@ The test suite produces different kind of artifacts: logfiles, screen
captures for failing steps, snapshots of the test VM, and also videos of
the running test session.
-Videos may be a bit too much to keep, given they slow down the test
-suite and might take quite a bit of disk space to store. If we want to
-keep them, we may want to do so only for failing test suite runs. If we
-decide to still use them, then we probably have to wait for
-[[!tails_ticket 10001]] too be resolved.
+We can keep the video captures in the build artifacts, now that
+[[!tails_ticket 10001]] is resolved.
-Proposal for a first iteration:
+Decision:
* For green test suite run: keep the test logs (Jenkins natively do
that).
- * For red test suite run: keep the screen and video captures, the
+ * For red test suite run: keep the screenshots and video captures, the
logs and the pcap files.
-On the second iteration, we will keep video capture only for the red
-tests.
-
-The retention strategy should be the same than for the automatically
-built ISOs. In particular, we will have to pay attention to the rotation
-of videos capture (given they'll quickly bloat our storage space).
-Keeping them only for 7 days sounds reasonnable.
+In [[!tails_ticket 10155]] we calculated that we can probably keep the
+video captures for a full release cycle. This will be refine is reality
+claims the contrary after an evaluation.
# Scenarios
diff --git a/wiki/src/blueprint/automated_builds_and_tests/jenkins.mdwn b/wiki/src/blueprint/automated_builds_and_tests/jenkins.mdwn
index 1d0eb88..0e9902c 100644
--- a/wiki/src/blueprint/automated_builds_and_tests/jenkins.mdwn
+++ b/wiki/src/blueprint/automated_builds_and_tests/jenkins.mdwn
@@ -1,152 +1,41 @@
-[[!meta title="Jenkins"]]
+[[!meta title="Automated tests implementation details"]]
+
+For Jenkins resources, see [[blueprint/automated_builds_and_tests/resources]].
[[!toc levels=2]]
-Resources
-=========
-
-Miscellaneous
--------------
-
-- [Jenkins Best
- Practices](https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Best+Practices)
-- [plugins](https://wiki.jenkins-ci.org/display/JENKINS/Plugins)
- * [Git plugin](https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin)
- * [Copy Artifact
- plugin](https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin)
- can be used to run a test job against the result of a build job,
- e.g. for Debian packages (think Lintian) or Tails ISO images; see
- [grml's setup
- documentation](http://jenkins-debian-glue.org/getting_started/manual/)
- that uses it.
-- the [jenkins](http://jujucharms.com/charms/precise/jenkins) and
- [jenkins-slave](http://jujucharms.com/charms/precise/jenkins-slave)
- JuJu charms may be good sources of inspiration for deployment
-- [[!cpan Net-Jenkins]] (not in Debian) allows to interact with
- a Jenkins server: create and start jobs, get information about
- builds etc.
-
-Jobs management
----------------
-
-- [Job builder](http://ci.openstack.org/jenkins-job-builder/) provides
- one-way (Git to Jenkins) jobs synchronization; it's in Debian sid.
- * [configuration documentation](http://ci.openstack.org/jenkins-job-builder/configuration.html)
- * Debian uses it in their `update_jdn.sh`: it runs `jenkins-jobs
- update $config` after importing updated YAML job config files
- from Git.
- * Tor [use
- it](https://gitweb.torproject.org/project/jenkins/jobs.git/tree) too.
-- jenkins.debian.net uses the [SCM
- Sync](https://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin)
- plugin, that apparently handles committing to the VCS on
- configuration changes done in the web interface, and maybe more.
-- [jenkins-yaml](https://github.com/varnish/jenkins-yaml) might make
- it easy to generate a large number of similar Jenkins jobs, e.g.
- one per branch
-- [jenkins_jobs puppet module](http://tradeshift.com/blog/tstech-managing-jenkins-job-configurations-by-puppet/)
-
-Web setup
----------
-
-### Visible read-only on the web
-
-We'd like our Jenkins instance to be visible read-only on the web.
-We'd rather not rely on Jenkins authentication / authorization to
-enforce this read-only policy. We'd rather see the frontend reverse
-proxy take care of this.
-
-The
-[`getUnprotectedRootActions()`](http://javadoc.jenkins-ci.org/jenkins/model/Jenkins.html#getUnprotectedRootActions())
-method should return the list of URL prefixes that we want to allow.
-And we could forbid anything else.
-
-The [Reverse Proxy
-Auth](https://wiki.jenkins-ci.org/display/JENKINS/Reverse+Proxy+Auth+Plugin)
-Jenkins plugin can be useful to display [an example
-usage](https://github.com/jenkinsci/reverse-proxy-auth-plugin/commit/72567a974960be2363107614ba3f705ec6e9b695)
-of this method.
-
-### Miscellaneous
-
-- [sample nginx configuration](https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu)
-
-Notifications
--------------
-
-- [IRC plugin](https://wiki.jenkins-ci.org/display/JENKINS/IRC+Plugin),
- but I'm told that the jenkins email notifications are way nicer
- than what this plugin can do, so see [a better way to do
- it](http://jenkins.debian.net/userContent/setup.html#_installing_kgb_client)
-- [[!cpan Jenkins-NotificationListener]] is a server that listens to
- messages from Jenkins [Notification
- plugin](https://wiki.jenkins-ci.org/display/JENKINS/Notification+Plugin).
-
-### Notifying different people depending on what triggered the build
-
-At least the obvious candidate (Email-ext plugin) doesn't seem able to
-email different recipients depending on what triggered the build
-out-of-the-box. But apparently, one can set up two 'Script - After
-Build' email triggers in the Email-ext configuration: one emails the
-culprit, the other emails the RM. And then, they do something or not
-depending on a variable we set during the build, based on what
-triggered the build. Likely the cleaner and simpler solution.
-
-Otherwise, we could have Jenkins email some pipe script that will
-forward to the right person depending on 1. whether it's a base
-branch; and 2. whether the build was triggered by a push or by
-something else. This should work if we can get the email notification
-to pass the needed info in it. E.g. the full console output currently
-has "Started by timer" or "Started by an SCM change", but this is not
-part of the email notification. Could work, but a bit hackish and all
-kinds of things can go wrong.
-
-Also, I've seen lots of people documenting crazy similar things with
-some of these plugins: "Run Condition", "Conditional BuildStep",
-"Flexible Publish" and "Any Build step". But then it gets too
-complicated for me to dive into it right now.
-
-How others use Jenkins
-----------------------
-
-- jenkins.debian.net's:
- * [setup documentation](http://jenkins.debian.net/userContent/setup.html)
- * configuration: `git://git.debian.org/git/users/holger/jenkins.debian.net.git`
-- [Tor's jobs](https://gitweb.torproject.org/project/jenkins/jobs.git/blob/HEAD:/jobs.yaml)
-- [Ubuntu QA Jenkins instance](https://jenkins.qa.ubuntu.com/)
-- grml's Michael Prokop talks about autotesting in KVM during his
- [talk at DebConf
- 10](http://penta.debconf.org/dc10_schedule/events/547.en.html);
- they use Jenkins:
- * [Jenkins instance](http://jenkins.grml.org/)
- * [unittests](https://github.com/grml/grml-unittests)
- * [debian-glue Jenkins plugin](https://github.com/mika/jenkins-debian-glue)
- * [kantan](https://github.com/mika/kantan): simple test suite for
- autotesting using Grml and KVM
- * [Jenkins server setup documentation](https://github.com/grml/grml-server-setup/blob/master/jenkins.asciidoc)
-- [jenkinstool](http://git.gitano.org.uk/personal/liw/jenkinstool.git/)
- has the tools Lars Wirzenius uses to manage his CI (Python projects
- test suite, Debian packages, importing into reprepro, VM setup of
- all needed stuff); the whole thing is very ad-hoc but many bits
- could be used as inspiration sources.
-
-Jenkins for Perl projects
--------------------------
-
-* [a collection of links](https://wiki.jenkins-ci.org/display/JENKINS/Perl+Projects)
- on the Jenkins wiki
-* an overview of the available tools: [[!cpan Task::Jenkins]]
-* [a tutorial](https://logiclab.jira.com/wiki/display/OPEN/Continuous+Integration)
-* [another tutorial](http://alexandre-masselot.blogspot.com/2011/12/perl-hudson-continuous-testing.html)
-* use [[!cpan TAP::Formatter::JUnit]] (in Wheezy) rather than the Jenkins TAP plugin
-* use `prove --timer` to know how long each test takes
+Generating jobs
+===============
+
+We use code that lay in three different Git repositories to generate
+automatically the list of Jenkins jobs for branches that are active in
+the Tails main Git repo.
+
+The first brick is the Tails
+[[!tails_gitweb_repo pythonlib]], which extracts the list of
+active branches and output the needed informations. This list is parsed
+by the `generate_tails_iso_jobs` script run by a cronjob and deployed by
+our [[!tails_gitweb_repo puppet-tails]]
+`tails::jenkins::iso_jobs_generator` manifest.
+
+This script output yaml files compatible with
+[jenkins-job-builder](http://docs.openstack.org/infra/jenkins-job-builder).
+It creates one `project` for each active branches, which in turn uses
+three JJB `job templates` to create the three jobs for each branch: the
+ISO build one, and wrapper job that is used to start the ISO test jobs.
+
+This changes are pushed to our [[!tails_gitweb_repo jenkins-jobs]] git
+repo by the cronjob, and thanks to their automatic deployment in our
+`tails::jenkins::master` and `tails::gitolite::hooks::jenkins_jobs`
+manifests in our [[!tails_gitweb_repo puppet-tails]] repo, this new
+changes are applied automatically to our Jenkins instance.
Restarting slave VMs between jobs
----------------------------------
+=================================
This question is tracked in [[!tails_ticket 9486]].
-When we tackle [[!tails_ticket 5288]], if the test suite doesn't
+For [[!tails_ticket 5288]] to be robust enough, if the test suite doesn't
_always_ clean between itself properly (e.g. when tests simply hang
and timeout), we might want to restart `isotesterN.lizard` between
each each ISO testing job.
@@ -164,44 +53,35 @@ This was discussed at least there:
* <http://jenkins-ci.361315.n4.nabble.com/How-to-reboot-a-slave-during-a-build-td4628820.html>
* <https://stackoverflow.com/questions/5543413/reconfigure-and-reboot-a-hudson-jenkins-slave-as-part-of-a-build>
-That would maybe be the way to go, with 3 chained jobs:
+We achieve this VM reboot by using 3 chained jobs:
* First one is a wrapper and trigger 2 other jobs. It is executed on the
isotester the test job is supposed to be assigned to. It puts the
isotester in offline mode and starts the second job, blocking while
waiting for it to complete. This way this isotester is left reserved
- for the second job, and the isotester name can be passed as a build
+ while the second job run, and the isotester name can be passed as a build
parameter to the second job. This job is low prio so it waits for
other second and third type of jobs to be completed before starting its
own.
-* The second job is executed on the master (which has two build
+* The second job is executed on the master (which has 4 build
executors). This job ssh into the said isotester and issue the
- reboot. It waits a bit and put the node back online again. This jobs
- is higher prio so that it is not lagging behind other wrapper jobs in
- the queue.
+ reboot. It needs to wait a reasonable amount of time for the Jenkins
+ slave to be stopped by the shutdown process so that no jobs gets assigned
+ to this isotester meanwhile. Stoping this Jenkins slave daemon usually
+ takes a few seconds. During testing, 5 seconds proved to be enough of
+ a delay for that, and more would mean unnecessary lagging time. It then
+ put the node back online again. This job is higher prio so that it is
+ not lagging behind other wrapper jobs in the queue.
* The third job is the test job, run on the freshly started isotester.
This one is high prio too to get executed before any other wrapper
- jobs.
-
-Using some kind of queue sorting is necessary. Unfortunately, the
-[PrioritySorter
-plugin](https://wiki.jenkins-ci.org/display/JENKINS/Priority+Sorter+Plugin)
-is not well supported by the current version of JJB in Debian. We'll
-have to push upstream a fix, and meanwhile use the `raw` option trick in
-the yaml files (which itself isn't supported by JJB in Debian yet,
-hopefully the new one will leave the NEW queue soon).
-
-Another tested but non-working option was to use the Jenkins [PostBuildScript
-plugin](https://wiki.jenkins-ci.org/display/JENKINS/PostBuildScript%20Plugin)
-to issue a `shutdown -r` command at the end of the job. There are
-indications that [people are using it like
-this](https://stackoverflow.com/questions/11160363/execute-shell-script-after-post-build-in-jenkins)
-already. It's supported by JJB.
+ jobs. These jobs are set to run concurrently, so that if a first one is
+ already running, a more recent one triggered by a new build will still
+ be able to run and not be blocked by the first running one.
<a id="chain"></a>
Chaining jobs
--------------
+=============
There are several plugins that allow to chain jobs that we might use to
run the test suite job following a build job of a branch.
@@ -228,33 +108,11 @@ run the test suite job following a build job of a branch.
These are all supported by JJB v0.9+.
-One solution that could work and won't require more additionnal plugins
-to manage could be to make an extensive use of the EnvInject plugin in
-the same way we already use it to configure the notification. Then we
-would be able to simply use Jenkins' native way of chaining jobs:
-
- * At the beginning of the build job, a script (in our jenkins-tools
- repo) is collecting every necessary parameters defined in the
- automated test blueprin and outputing them in a file in the
- /build-artifacts/ directory.
- * This file is the one used by the build job, to setup the variables it
- needs (currently only $NOTIFY_TO).
- * At the end of the build job, this file is archived with the other
- artifacts.
- * At the beginning of the chained test job, this file is imported in
- the workspace along with the build artifacts. The EnvInject pre-build
- step uses it to setup the necessary variables.
-
-Where I'm not sure is that the Jenkins's native way can collaborate
-smoothly with the EnvInject plugin. Maybe the different steps we are
-talking about don't happen in an order that would fit this scenario.
-Might be that we'll have to use the ParameterizedTrigger plugin. Might
-also be that we don't need the EnvInject plugin in the test job, but
-just import the variables in the environment in the test suite wrapper
-script.
+As we'll have to pass some parameters, the ParameterizedTrigger plugin
+is the best candidate for us.
Passing parameters through jobs
--------------------------------
+===============================
We already specified what kind of informations we want to pass from the
build job to the test job.
@@ -262,14 +120,23 @@ build job to the test job.
The ParameterizedTiggerPlugin is the one usually used for that kind of
work.
-An other way that seem to be possible/used with the Jenkins native job
-chaining ability is to put the wanted parameters in a file that is
-archived with the artifacts of the upstream job. Then the downstream job
-can be configured with then EnvInject plugin we already use to set the
-necessary variables in the job environment.
+We'll use it for some basic parameter passing through jobs, but given
+the test jobs will need to know a lot of them from the build job, we'll
+also use the EnvInject plugin we're already using:
+
+ * In the build job, a script will collect every necessary parameters
+ defined in the automated test blueprint and outputing them in a file
+ in the /build-artifacts/ directory.
+ * This file is the one used by the build job, to setup the variables it
+ needs (currently only $NOTIFY_TO).
+ * At the end of the build job, this file is archived with the other
+ artifacts.
+ * At the beginning of the chained test job, this file is imported in
+ the workspace along with the build artifacts. The EnvInject pre-build
+ step uses it to setup the necessary variables.
Define which $OLD_ISO to test against
--------------------------------------
+=====================================
It appeared in [[!tails_ticket 10117]] that this question is not so
obvious and easy to address.
@@ -296,19 +163,19 @@ we'll have to merge the base branch before we look at that config
setting (because for some reason the base branch might itself require
old ISO = same).
-As a first baby step, we will by default use the same ISO for both
-`--old-iso` and `--iso`, except for the branches used to prepare
-releases (`devel` and `stable`), so that we
-know if the upgrades are broken long before the next release.
-
Another option that could be considered, using existing code in the repo: use the
`OLD_TAILS_ISO` flag present in `config/default.yml`: when we release we
set its value to the released ISO, and for some branch that need it we
empty this variable so that the test use the same ISO for both
`--old-iso` and `--iso`.
+In the end, we will by default use the same ISO for both `--old-iso` and
+`--iso`, except for the branches used to prepare releases (`devel` and
+`stable`), so that we know if the upgrades are broken long before the
+next release.
+
Retrieving the ISOs for the test
---------------------------------
+================================
We'll need a way to retrieve the different ISO needed for the test.
@@ -323,4 +190,4 @@ For the last release ISO, we have several means:
vhost for the isotesters.
* Using the git-annex repo directly.
-The former is probably the most simple to use.
+We'll use the first one, as it's easier to implement.
diff --git a/wiki/src/blueprint/automated_builds_and_tests/resources.mdwn b/wiki/src/blueprint/automated_builds_and_tests/resources.mdwn
new file mode 100644
index 0000000..0368eb6
--- /dev/null
+++ b/wiki/src/blueprint/automated_builds_and_tests/resources.mdwn
@@ -0,0 +1,140 @@
+[[!meta title="Jenkins resources"]]
+
+[[!toc levels=2]]
+
+Miscellaneous
+=============
+
+- [Jenkins Best
+ Practices](https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Best+Practices)
+- [plugins](https://wiki.jenkins-ci.org/display/JENKINS/Plugins)
+ * [Git plugin](https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin)
+ * [Copy Artifact
+ plugin](https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin)
+ can be used to run a test job against the result of a build job,
+ e.g. for Debian packages (think Lintian) or Tails ISO images; see
+ [grml's setup
+ documentation](http://jenkins-debian-glue.org/getting_started/manual/)
+ that uses it.
+- the [jenkins](http://jujucharms.com/charms/precise/jenkins) and
+ [jenkins-slave](http://jujucharms.com/charms/precise/jenkins-slave)
+ JuJu charms may be good sources of inspiration for deployment
+- [[!cpan Net-Jenkins]] (not in Debian) allows to interact with
+ a Jenkins server: create and start jobs, get information about
+ builds etc.
+
+Jobs management
+===============
+
+- [Job builder](http://ci.openstack.org/jenkins-job-builder/) provides
+ one-way (Git to Jenkins) jobs synchronization; it's in Debian sid.
+ * [configuration documentation](http://ci.openstack.org/jenkins-job-builder/configuration.html)
+ * Debian uses it in their `update_jdn.sh`: it runs `jenkins-jobs
+ update $config` after importing updated YAML job config files
+ from Git.
+ * Tor [use
+ it](https://gitweb.torproject.org/project/jenkins/jobs.git/tree) too.
+- jenkins.debian.net uses the [SCM
+ Sync](https://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin)
+ plugin, that apparently handles committing to the VCS on
+ configuration changes done in the web interface, and maybe more.
+- [jenkins-yaml](https://github.com/varnish/jenkins-yaml) might make
+ it easy to generate a large number of similar Jenkins jobs, e.g.
+ one per branch
+- [jenkins_jobs puppet module](http://tradeshift.com/blog/tstech-managing-jenkins-job-configurations-by-puppet/)
+
+Web setup
+=========
+
+### Visible read-only on the web
+
+We'd like our Jenkins instance to be visible read-only on the web.
+We'd rather not rely on Jenkins authentication / authorization to
+enforce this read-only policy. We'd rather see the frontend reverse
+proxy take care of this.
+
+The
+[`getUnprotectedRootActions()`](http://javadoc.jenkins-ci.org/jenkins/model/Jenkins.html#getUnprotectedRootActions())
+method should return the list of URL prefixes that we want to allow.
+And we could forbid anything else.
+
+The [Reverse Proxy
+Auth](https://wiki.jenkins-ci.org/display/JENKINS/Reverse+Proxy+Auth+Plugin)
+Jenkins plugin can be useful to display [an example
+usage](https://github.com/jenkinsci/reverse-proxy-auth-plugin/commit/72567a974960be2363107614ba3f705ec6e9b695)
+of this method.
+
+### Miscellaneous
+
+- [sample nginx configuration](https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu)
+
+Notifications
+=============
+
+- [IRC plugin](https://wiki.jenkins-ci.org/display/JENKINS/IRC+Plugin),
+ but I'm told that the jenkins email notifications are way nicer
+ than what this plugin can do, so see [a better way to do
+ it](http://jenkins.debian.net/userContent/setup.html#_installing_kgb_client)
+- [[!cpan Jenkins-NotificationListener]] is a server that listens to
+ messages from Jenkins [Notification
+ plugin](https://wiki.jenkins-ci.org/display/JENKINS/Notification+Plugin).
+
+### Notifying different people depending on what triggered the build
+
+At least the obvious candidate (Email-ext plugin) doesn't seem able to
+email different recipients depending on what triggered the build
+out-of-the-box. But apparently, one can set up two 'Script - After
+Build' email triggers in the Email-ext configuration: one emails the
+culprit, the other emails the RM. And then, they do something or not
+depending on a variable we set during the build, based on what
+triggered the build. Likely the cleaner and simpler solution.
+
+Otherwise, we could have Jenkins email some pipe script that will
+forward to the right person depending on 1. whether it's a base
+branch; and 2. whether the build was triggered by a push or by
+something else. This should work if we can get the email notification
+to pass the needed info in it. E.g. the full console output currently
+has "Started by timer" or "Started by an SCM change", but this is not
+part of the email notification. Could work, but a bit hackish and all
+kinds of things can go wrong.
+
+Also, I've seen lots of people documenting crazy similar things with
+some of these plugins: "Run Condition", "Conditional BuildStep",
+"Flexible Publish" and "Any Build step". But then it gets too
+complicated for me to dive into it right now.
+
+How others use Jenkins
+======================
+
+- jenkins.debian.net's:
+ * [setup documentation](http://jenkins.debian.net/userContent/setup.html)
+ * configuration: `git://git.debian.org/git/users/holger/jenkins.debian.net.git`
+- [Tor's jobs](https://gitweb.torproject.org/project/jenkins/jobs.git/blob/HEAD:/jobs.yaml)
+- [Ubuntu QA Jenkins instance](https://jenkins.qa.ubuntu.com/)
+- grml's Michael Prokop talks about autotesting in KVM during his
+ [talk at DebConf
+ 10](http://penta.debconf.org/dc10_schedule/events/547.en.html);
+ they use Jenkins:
+ * [Jenkins instance](http://jenkins.grml.org/)
+ * [unittests](https://github.com/grml/grml-unittests)
+ * [debian-glue Jenkins plugin](https://github.com/mika/jenkins-debian-glue)
+ * [kantan](https://github.com/mika/kantan): simple test suite for
+ autotesting using Grml and KVM
+ * [Jenkins server setup documentation](https://github.com/grml/grml-server-setup/blob/master/jenkins.asciidoc)
+- [jenkinstool](http://git.gitano.org.uk/personal/liw/jenkinstool.git/)
+ has the tools Lars Wirzenius uses to manage his CI (Python projects
+ test suite, Debian packages, importing into reprepro, VM setup of
+ all needed stuff); the whole thing is very ad-hoc but many bits
+ could be used as inspiration sources.
+
+Jenkins for Perl projects
+=========================
+
+* [a collection of links](https://wiki.jenkins-ci.org/display/JENKINS/Perl+Projects)
+ on the Jenkins wiki
+* an overview of the available tools: [[!cpan Task::Jenkins]]
+* [a tutorial](https://logiclab.jira.com/wiki/display/OPEN/Continuous+Integration)
+* [another tutorial](http://alexandre-masselot.blogspot.com/2011/12/perl-hudson-continuous-testing.html)
+* use [[!cpan TAP::Formatter::JUnit]] (in Wheezy) rather than the Jenkins TAP plugin
+* use `prove --timer` to know how long each test takes
+
diff --git a/wiki/src/blueprint/l10n_Italian.mdwn b/wiki/src/blueprint/l10n_Italian.mdwn
index ea16bea..84e3721 100644
--- a/wiki/src/blueprint/l10n_Italian.mdwn
+++ b/wiki/src/blueprint/l10n_Italian.mdwn
@@ -40,24 +40,42 @@ to add it, run:
#Git comandi quotidiani
Sono tutti da mandare da terminale, una volta che si è dentro alla cartella che si usa per il progetto tails.
-Il pulsante TAB è vostro amico per completare tutti i percorsi dei file e soprattutto quando usate git add.
+Il pulsante TAB è vostro amico per completare tutti i percorsi dei file e soprattutto quando usate git add. Le frecce su e giù della tastiera vi danno gli ultimi comandi che avete lanciato, così andate velocissim*.
+
+Tutte le volte va configurata la chiave ssh che si usa, quindi:
+
+ $ ssh-add /home/utente/vostrachiaveprivata
+
+Fatto, ora possimo sincronizzarsi al repository remoto, prendendo i file che ci mancano:
$ git pull
-Per sincronizzarsi al repository remoto
+Per aggiungere allo stadio "stage" i file che poi si manderà al repository remoto.
+
$ git add NAMEFILE
-Per aggiungere allo stadio "stage" i file che poi si manderà al repository remoto
+Per avere una descrizione delle modifiche fatte localmente, ma che apparirà anche al repository remoto quando si aggiungeranno
+
$ git commit -m "DESCRIZIONE DELLE MODIFICHE FATTE"
-Per avere una descrizione delle modifiche fatte localmente, ma che apparirà anche al repository remoto quando si aggiungeranno
+Se siete sicuri che le modifiche che avete fatto vanno tutte sul repository remoto, potete condensare i due comandi sopra con uno solo, -a mette tutti i file nella zona "stage" e committate direttamente:
+
+ $ git commit -a -m "DESCRIZIONE MODIFICHE"
+
+Se non sapete l'identità con cui è configurato git, fate un controllo prima di mandare le cose in remoto:
+
+
+ $ git config -l
+
+Per aggiungere i commit fatti al repository remoto:
-
$ git push l10n-italian master
-Per aggiungere i commit fatti al repository remoto
+In caso di dubbi, vedete un po il vosro status:
+
+ $ git status
@@ -149,8 +167,11 @@ in fondo al comando):
11)Genero la chiave ssh, la invio agli sviluppatori TAILS(il file.pub) e l'associo per essere autenticato sul server:
ssh-keygen -t rsa -b 4096 -C "ignifugo@blablabla.net"
- $ eval "$(ssh-agent -s)"
- Agent pid 12534
+
+Ti chiederà il nome con cui genererà i due file della chiave, quello pubblico e quello segreto. QUindi ti cheide una passwor, due volte; i caratteri non si vedono quando li digiti.Finito
+
+Ora configuro la comunicazione ssh ad usare la mia chiave segreta ed invio quella pubblica agli sviluppatori di Tails per poter così scrivere nel repository condiviso.
+
$ ssh-add /home/cri/ignissh
Enter passphrase for /home/cri/ignissh:
Identity added: /home/cri/ignissh (/home/cri/ignissh)
@@ -196,34 +217,35 @@ Attingere nuove pagine da tradurre dando precedenza a queste:
./doc/about/requirements --DONE, pushed, daRev
-./doc/download
+./doc/download --DONE, pushed, daRev
-./doc/get.index
+./doc/get.index --DONE, pushed, daRev
-./doc/get/trusting_tails_signing_key
+./doc/get/trusting_tails_signing_key --DONE, pushed, daRev
-./doc/get/*
+./doc/get/*--DONE, pushed, daRev
___
bf
./doc/about.index --FINITO!
-./doc/about/openpgp_keys --80% DONE, a lot of issues... daRev ?
-
-./doc/about/features --DONE, pushed daRev ?
+./doc/about/features --DONE, pushed daRev
-./doc/about/fingerprint --DONE, pushed daRev ?
+./doc/about/fingerprint --DONE, pushed daRev
./doc/first_steps/persistence.caution --FINITO!
-./doc/first_steps/persistence/configure --DONE pushed daRev ?
+./doc/first_steps/persistence/configure --DONE pushed daRev
./doc/first_steps/persistence/delete --FINITO!
+./doc/first_steps/persistence/warnings --FINITO!
+
+***
./doc/first_steps/persistence/use
-./doc/first_steps/persistence/warnings --FINITO!
+./doc/about/openpgp_keys --80% DONE, a lot of issues... not pushed
___
./doc/about/tor --DONE, Pushed
diff --git a/wiki/src/blueprint/monthly_meeting.mdwn b/wiki/src/blueprint/monthly_meeting.mdwn
index 121ad06..7302c27 100644
--- a/wiki/src/blueprint/monthly_meeting.mdwn
+++ b/wiki/src/blueprint/monthly_meeting.mdwn
@@ -16,6 +16,4 @@ Availability and plans for the next weeks
Discussions
===========
- - [[!tails_ticket 10257 desc="Discuss & adopt a strategy to merge commits from Weblate"]]
- - [[!tails_ticket 10179 desc="Document mentors for new contributors"]]
- - [[!tails_ticket 10024 desc="Document issues behind having Tails derivatives"]]
+ - [[!tails_ticket 10188 desc="Draft text for the website about buying t-shirts"]]
diff --git a/wiki/src/blueprint/report_2015_08.mdwn b/wiki/src/blueprint/report_2015_08.mdwn
index 111e870..b679edd 100644
--- a/wiki/src/blueprint/report_2015_08.mdwn
+++ b/wiki/src/blueprint/report_2015_08.mdwn
@@ -18,16 +18,25 @@ Releases
Code
====
-FIXME
+## Upgrades and changes
-* Alan submitted for review a new version of
- [Tor Monitor](https://mailman.boum.org/pipermail/tails-dev/2015-August/009381.html)
- (to replace Vidalia) and Sascha Steinbiss proposed to
- [package it for Debian](https://mailman.boum.org/pipermail/tails-dev/2015-August/009397.html).
+- Install Tor Browser 5.0.2 (based on Firefox ESR 38.2.1).
+
+- Install a 32-bit GRUB EFI boot loader. Tails should now start on some tablets
+with Intel Bay Trail processors among others.
+
+- Let the user know when Tails Installer has rejected a device because it is too
+small.
+
+- Upgrade Tor to 0.2.6.10-1~d70.wheezy+1+tails1
+
+## Fixed problems
+
+- Our AppArmor setup has been audited and improved in various ways which should
+harden the system.
+
+- The network should now be properly disabled when MAC address spoofing fails.
-* We drafted a script to [[!tails_ticket 9993 desc="run a Mumble server"]] from
- Tails, verified that the Mumble client in Tails Jessie works well, and
- started using it for internal meetings.
Documentation and website
=========================
@@ -108,12 +117,19 @@ Upcoming events
On-going discussions
====================
-FIXME
+* Alan submitted for review a new version of
+ [Tor Monitor](https://mailman.boum.org/pipermail/tails-dev/2015-August/009381.html)
+ (to replace Vidalia) and Sascha Steinbiss proposed to
+ [package it for Debian](https://mailman.boum.org/pipermail/tails-dev/2015-August/009397.html).
+
+* We drafted a script to [[!tails_ticket 9993 desc="run a Mumble server"]] from
+ Tails, verified that the Mumble client in Tails Jessie works well, and
+ started using it for internal meetings.
Press and testimonials
======================
-FIXME
+* 2015-08-04: [Cinq systèmes d’exploitation pour snober Windows 10 (et Mac OS)](http://www.lemonde.fr/pixels/article/2015/08/04/cinq-systemes-d-exploitation-pour-snober-windows-10-et-mac-os_4710726_4408996.html) by Damien Leloup in Le Monde (in French).
Translation
===========