Tails

#1 Updated by sajolida 2018-01-17 18:02:21

• related to Bug #12005: Problems with DAVE manual tests added

#2 Updated by sajolida 2018-01-17 18:27:59

• related to Bug #12683: Move DAVE manual test suite out of the Tails release process added

#3 Updated by sajolida 2018-01-17 20:37:07

• Assignee changed from sajolida to intrigeri
• Priority changed from Elevated to Normal
• QA Check set to Ready for QA

Done in 1d8aa4d.

Regarding when to run it, cf. Bug #12683:

• Running it whenever we publish a new version of Tails Verification seems obvious.

• Running it whenever “a new Firefox is released” seems too much work for me. If we’re talking about official release that was 7 in 2017 for Firefox only. If we add 10 stable releases for Chrome that’s a lot. I’d like to find a lower number, just to make sure that we test Tails Verification at least a couple times a year but not every month. Maybe once the next ESR becomes beta? But I’m not well versed enough in the Firefox release cycle to be sure…

intrigeri: Do you want to have a look? Otherwise I’ll ask anonym.

#4 Updated by intrigeri 2018-01-18 11:24:32

• Status changed from Confirmed to In Progress
• Assignee changed from intrigeri to sajolida
• % Done changed from 0 to 60
• QA Check changed from Ready for QA to Dev Needed

sajolida wrote:
> Done in 1d8aa4d.

I struggled to find that commit until it occurred to me that it could (should!) be in verification-extension.git.

> Regarding when to run it, cf. Bug #12683:
>
> * Running it whenever we publish a new version of Tails Verification seems obvious.

Yep. Chances are this does not happen very often: once the add-on is finalized I suspect we won’t release more than once a year on average.

> * Running it whenever “a new Firefox is released” seems too much work for me. If we’re talking about official release that was 7 in 2017 for Firefox only. If we add 10 stable releases for Chrome that’s a lot. I’d like to find a lower number, just to make sure that we test Tails Verification at least a couple times a year but not every month. Maybe once the next ESR becomes beta? But I’m not well versed enough in the Firefox release cycle to be sure…

Taking a step back: every major Firefox release has the potential to break our extension. I understand that manually testing all this 7 times a year is a big burden. Mozilla tells add-on developers in advance about incompatible changes, so I’d rather see us spend time to follow this proactively than to try to notice when it’s too late that there’s adjustments we should have done before the new Firefox release. It’s probably similar in the Chrome world.

So let’s try “when the Firefox beta channel tracks the future release that will become the next ESR”, it’s a good starting point. If we notice we missed breakage until our Help Desk / Twitter / reddit / XMPP shout at us, we can readjust frequency later.

> intrigeri: Do you want to have a look?

Yes.

• The example command lines assume a Debian stable system. I trust your choice in that matter but it should be documented.
• It’s not obvious to me why we do sudo apt purge firefox-esr ; apt install firefox-esr (and don’t do the same for the other browsers).
• We too often see code working and tests passing just fine in en_US locales but failing in other locales. So I propose we suggest running these tests in another locale (that the tester can choose themselves).

That’s all!

#5 Updated by anonym 2018-01-23 19:52:42

• Target version changed from Tails_3.5 to Tails_3.6

#7 Updated by sajolida 2018-01-31 15:55:31

• Assignee changed from sajolida to intrigeri
• QA Check changed from Dev Needed to Ready for QA

#8 Updated by intrigeri 2018-02-02 14:43:22

• Assignee changed from intrigeri to sajolida
• QA Check changed from Ready for QA to Dev Needed

>> So let’s try “when the Firefox beta channel tracks the future release that will become the next ESR”, it’s a good starting point.

> When can such an event be tracked?

See the links on top of https://tails.boum.org/contribute/working_together/roles/release_manager/.

Everything else looks good up to commit 1d8aa4d757e8b1e11d0f3ec2e970aea00c7812f6 \o/

#9 Updated by sajolida 2018-03-02 15:53:49

• Assignee changed from sajolida to intrigeri
• QA Check changed from Dev Needed to Ready for QA

anonym helped me decipher the Firefox calendar and I wrote it with 1a71457 in a way that I can understand it in the future.

I also created a ticket to test it in Firefox 60: Feature #15366.

#10 Updated by intrigeri 2018-03-05 08:03:21

• Status changed from In Progress to Resolved
• Assignee deleted (intrigeri)
• % Done changed from 60 to 100
• QA Check changed from Ready for QA to Pass

In the future please avoid rewriting history that’s already been published to the master branch and that I’ve already reviewed (the latter makes my work more painful than it should be).

Other than that, looks good to me!