Test and release new Tails Verification
Reviewer and rubber-duck: intrigeri
#3 Updated by intrigeri 2018-11-20 09:50:58
Not sure where I should write this because it’s about coordinating stuff that’s happening in a bunch of different tickets assigned to different people.
Given the IDF format will change, we’ll switch to
install/v2/**/*.json. So we’ll need to talk a bit about how we coordinate three things:
- when we start publishing
- when we stop publishing
- when you release the new Tails Verification (this very ticket)
- when the install doc starts requiring the new version of Tails Verification
The only part of that on which I’ll need an answer soon is “when we stop publishing
install/v1/**/*.yml”: depending on our plan, either I’ll replace v1 generation with v2, or I’ll keep generating v1 for some time if that’s useful.
So let’s talk, e.g. during or after the next USB image meeting :)
#4 Updated by sajolida 2018-11-29 15:39:26
We can force people to update their version of the extension and this work pretty well.
keyringer internal decrypt credentials.asc | grep addons.mozilla.org
So we don’t need to ship both v1 and v2 in parallel during several days, only during the transition to make sure that nobody gets a broken download page. I think it’s enough for me to have all the pieces ready and deal with the change from v1 to v2 during the release of the new extension. I mean in the same day:
- Test the new extension locally.
- Add v2 on the website.
- Release the new extension.
- Test the new extension remotely.
- Force the new extension on the website.
- Remove v1 from the website.
For me to do this alone, I guess I would only need a branch that adds v2. I can remove v1 with a
We could even leave v1 around until the next release. It shouldn’t be necessary but I don’t see how it could hurt.
#6 Updated by intrigeri 2018-11-29 16:33:37
> We can force people to update their version of the extension and this work pretty well.
Your plan totally makes sense to me.
> For me to do this alone, I guess I would only need a branch that adds v2.
I’ve prepared it on
> I can remove v1 with a
> We could even leave v1 around until the next release. It shouldn’t be necessary but I don’t see how it could hurt.
Indeed, I see no reason to both removing it particularly early: my branch for
Bug #15999 deletes it and removes the doc that leads the RM to generate it. That branch will be merged into devel at the same time as the rest of our USB image work, targetted at 3.12.
#9 Updated by Anonymous 2018-12-17 15:37:58
- Feature Branch set to verification-extension:usbimage
This is now ready to be published.
- enrico did several code reviews.
- intrigeri has reviewed and tested the branch in https://redmine.tails.boum.org/code/issues/15995 and improved the testing instructions a bit.
- intrigeri and me have noted in https://redmine.tails.boum.org/code/issues/15995#note-88 on which browsers we tested it for your convenience.
It’s not been merged to master, I trust you to do that once happy.
I think you’ll need to adjust the minimum version in the download pages.
#12 Updated by sajolida 2018-12-25 19:12:35
- Assignee deleted (
- QA Check set to Info Needed
My local tests for ISO images went super smoothly, congrats!
I didn’t know how to test USB images as the IDF on the production website only mentions the ISO file.
How can I test that 2.0 works fine with USB images?
Still, as we’re only shipping ISO images as of now, I released version 2.0 on the app stores anyway.
But I really want to test 2.0 with USB images before we release 3.12.
#13 Updated by sajolida 2018-12-25 20:04:49
- Status changed from Confirmed to Resolved
- Assignee deleted (
- QA Check deleted (
I found out how to make the extension use a different IDF that I uploaded on another server and tested the verification of a USB image in different ways. Everything worked as expected. Excellent!
So I think we can close this ticket :)