Tails

#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 install/v2/**/*.json (Bug #15999)
• when we stop publishing install/v1/**/*.yml (Bug #15999 too)
• 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.

If you’re curious, see https://addons.mozilla.org/en-US/firefox/addon/tails-verification/statistics/usage/versions/?last=30.

Login: 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:

1. Test the new extension locally.
2. Add v2 on the website.
3. Release the new extension.
4. Test the new extension remotely.
5. Force the new extension on the website.
6. 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 git rm.

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

sajolida wrote:
> We can force people to update their version of the extension and this work pretty well.

Excellent!

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 Bug #16171.

> I can remove v1 with a git rm.
> 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.

#14 Updated by Anonymous 2018-12-27 09:37:16

Great!

If you can, it would be interesting to report the spent time on this task, so we can later compare that to the estimation. I would like to make that a habit for future projects :)