Tails

#1 Updated by Anonymous 2017-01-17 15:24:00

• related to Feature #8549: Have Tails Installer in Debian and Ubuntu added

#2 Updated by Anonymous 2017-01-18 21:23:18

• related to #11343 added

#3 Updated by intrigeri 2017-01-24 15:24:34

• Category set to Installation
• Status changed from New to Confirmed
• Affected tool set to Installer

> updating tails-installer for every Tails release might now not be necessary anymore

ACK!

> I think we still need to update the RM release process and documentation with this new information.

Absolutely. E.g. the Installer release process doc still assumes that only one Git repo is involved, while (if I got the outcome of Feature #10666 right) the packaging now lives in Debian’s Vcs-Git only (maybe it should be removed from the Tails repo btw), while upstream work is in the Tails repo.

> Maybe we also need to define how it will happen instead?

Good point!

If I got it right from Feature #10666, given the packaging will be done as part of pkg-privacy, the only thing may be needed on Tails side is to apply some urgent fix and upload a custom package until a problem is fixed in Debian. Just like the rest of our core code, preparing such fixes is on the Foundations Team’s plate (currently: anonym and I), and merging them is on the RM’s plate, unless they’ve prepared the fix themselves, in which case a member of the Foundations Team shall review’n’merge it.

Last year, I see that we’ve created new releases 3 times for other reasons than translations or fixing the initial Debian packaging. Ignoring again translations, packaging polishing, and the (unusual) work we did to make the app work on non-Tails + update to Jessie, I see 2 releases in 2015, and 8 in 2014. So it seems to me that we improve Tails Installer often enough to avoid ever having to prepare a new upstream release merely to import updated translations. Good, this will avoid adding too much bureaucracy! (i.e. a process to prepare a new release unless there’s been one recently enough, please, no)

So I propose that whoever merges a branch upstream (be it the RM or a member of the Foundations Team) is tasked with immediately preparing a new upstream release, and pinging the Debian maintainer somehow so that they import that release and upload it to Debian (+ backports for now).

Ideally, a new upstream release tag appearing in the upstream Git repo should be enough to warn the package maintainer(s), but I dunno how one can easily track this so let’s ignore it for now.

The outcome of Feature #10666 is not clear to me wrt. who imports the new upstream release into Vcs-Git and updates the packaging. I suspect it’s kinda blocked by #11343, so until that’s cleared, indeed all the RM and Foundations Team people need to be part of pkg-privacy if I got it right (this includes bertagaz, but frankly I doubt he’ll ever need to make use of it, and I’m fine with giving a hand to avoid forcing one more person to learn something they’ll barely ever need). Now, if that helps, I’m personally in favour of fixing #11343 ASAP so that we don’t have to waste time documenting that intermediate, temporary situation, and we can directly document how things will work afterwards, i.e. once we’re able to allow a Debian maintainer (u) to do her work in good conditions, which I think would be much better, as the upstream/Debian split would be much clearer and easier to understand, document, and implement.

#4 Updated by anonym 2017-04-19 17:37:27

• Target version changed from Tails_2.12 to Tails_3.0

#5 Updated by intrigeri 2017-05-27 08:28:19

• Target version changed from Tails_3.0 to Tails_3.1

At this point it doesn’t make much of a difference to postpone it a little bit more => please focus on 3.0 blockers.

#6 Updated by intrigeri 2017-06-29 10:32:36

• blocks Feature #13234: Core work 2017Q3: Foundations Team added

#7 Updated by anonym 2017-07-06 14:15:05

• Target version changed from Tails_3.1 to Tails_3.2

#8 Updated by anonym 2017-09-25 09:57:12

• Target version changed from Tails_3.2 to Tails_3.3

I started a bit on this on Feature #8860 (in the feature/8860-tails-installer-improvements branch). From Feature #8860#note-66:

• Debian “Testing” and “Unstable” are creations of your own. “testing/sid” (that we had before) is common as it used to be what one had in /etc/debian_version when running testing or unstable. “testing/unstable” would work too.
• I should not have let you bump the version to 5.x: our versioning scheme is meant to convey useful info to downstream package maintainers, and in that scheme this bump means “we’re breaking compatibility with Jessie” (which I hope we’re not). Anyway, too late, no big deal :)
• Your update to versions, branches etc. is much welcome, but the info about Jessie was lost: our current main upstream dev branch is supposed to support it (https://tails.boum.org/install/debian/usb/).
• Your changes in the “In practice, it’s expected that Tails contributors submit bugfix and” paragraph lose info that’s useful when we’re maintaining two dev branches at the same time (one for current Tails and one for Tails based on next Debian). No huge deal but it feels a bit sad to regress here.
• Similarly, with your changes in the “Update the Debian package” section, it now assumes that tails/master is the branch that works on current testing/sid, which is not always the case: sometimes we have to start a new (e.g. 6.x) dev branch to keep supporting it, while we’re still shipping something else (e.g. 5.x) in current Tails based on Debian stable. I think you can keep them all as-is (it’s good to have examples that work in the most common case) but please write something like “This assumes that the latest upstream release has been imported into a Tails packaging branch (e.g. `tails/master` or `tails/buster`) already” in the intro, to leave room for “tails/master is not always the right branch”.
• I understand what follows but I think many other readers will think these two bullet points contradicts each other as it’s not clear that tails/master is an exception to the 2nd rule:

* The `tails/master` branch is used to prepare packages that we upload
to the Tails APT repo for stable releases, but not to Debian.
* The `tails/$codename` branch is used to prepare packages that we upload
to the Tails APT repo but for Tails based on Debian `$codename`. Again,
these packages will not be uploaded to Debian.

#9 Updated by intrigeri 2017-10-01 09:50:03

• blocks Feature #13244: Core work 2017Q4: Foundations Team added

#10 Updated by intrigeri 2017-10-01 09:50:04

• blocked by deleted (Feature #13234: Core work 2017Q3: Foundations Team)

#11 Updated by anonym 2017-11-15 11:30:51

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

#12 Updated by intrigeri 2017-12-07 12:54:18

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

#13 Updated by intrigeri 2018-01-01 16:49:43

• blocked by deleted (Feature #13244: Core work 2017Q4: Foundations Team)

#14 Updated by intrigeri 2018-01-01 16:55:08

• blocks Feature #13245: Core work 2018Q1: Foundations Team added

#15 Updated by anonym 2018-02-26 10:49:10

• Priority changed from Normal to Elevated

#16 Updated by anonym 2018-02-26 17:09:30

• Status changed from Confirmed to In Progress
• Assignee changed from anonym to intrigeri
• % Done changed from 0 to 50
• QA Check set to Ready for QA

Thanks for your input! Commits referred to below are already pushed to master.

anonym wrote:
> I started a bit on this on Feature #8860 (in the feature/8860-tails-installer-improvements branch). From Feature #8860#note-66:
>
> * Debian “Testing” and “Unstable” are creations of your own. “testing/sid” (that we had before) is common as it used to be what one had in /etc/debian_version when running testing or unstable. “testing/unstable” would work too.

Fixed in commit:2b58254a3da44a3481041b2b146f8396734225a3.

> * I should not have let you bump the version to 5.x: our versioning scheme is meant to convey useful info to downstream package maintainers, and in that scheme this bump means “we’re breaking compatibility with Jessie” (which I hope we’re not). Anyway, too late, no big deal :)

Oh well…

> * Your update to versions, branches etc. is much welcome, but the info about Jessie was lost: our current main upstream dev branch is supposed to support it (https://tails.boum.org/install/debian/usb/).

Right… in Debian. Done in commit:bc471a761f02f71dbd38dc920619b17dbaa69f0e.

> * Your changes in the “In practice, it’s expected that Tails contributors submit bugfix and” paragraph lose info that’s useful when we’re maintaining two dev branches at the same time (one for current Tails and one for Tails based on next Debian). No huge deal but it feels a bit sad to regress here.

Fixed with commit:11e94a16abe61853fb23734ab84efde466de8643.

> * Similarly, with your changes in the “Update the Debian package” section, it now assumes that tails/master is the branch that works on current testing/sid, which is not always the case: sometimes we have to start a new (e.g. 6.x) dev branch to keep supporting it, while we’re still shipping something else (e.g. 5.x) in current Tails based on Debian stable. I think you can keep them all as-is (it’s good to have examples that work in the most common case) but please write something like “This assumes that the latest upstream release has been imported into a Tails packaging branch (e.g. `tails/master` or `tails/buster`) already” in the intro, to leave room for “tails/master is not always the right branch”.

Got it. I went with commit:9d911b2e75453bd68ff0a5d8f387ffddaf2f6e88. Looks ok?

> * I understand what follows but I think many other readers will think these two bullet points contradicts each other as it’s not clear that tails/master is an exception to the 2nd rule:
>
> […]

I barely get what’s unclear (for the target audience) but I attempted to make it clearer with commit:c47accdd0ad95af472654497972b194ec0d07bf7.

#17 Updated by intrigeri 2018-02-27 09:39:18

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

All these changes look good!

Three more comments:

The “Update debian/changelog” section could perhaps mention something about the common mistakes we’ve seen in the past, most notably:

• Every Tails ticket ID must be Tails#NNNNN, not #NNNNN and definitely not Closes: #NNNNN
• The raw data compiled by gbp dch must be edited to convey information that’s relevant and self-contained for a Debian audience (clearly our upstream commit messages are not written with this audience in mind). For example, the 5.0.4+dfsg-0tails1 changelog entry is pretty good, but things like “Apply awful hack to fix TailsBug #14755” are meaningless for a Debian audience.

Feel free to copy’n’paste my text above and be done with it.

Our end-user doc says we support Tails Installer on Jessie and Stretch but this piece of doc only mentions jessie-backports (which is actually incorrect because we cannot upload to jessie-backports a package that’s not in Stretch but let’s ignore this for now; reported on Bug #14650#note-22). I think it should mention stretch-backports as well.

debian/README.source has a fork of part of this documentation. Ulrike has improved/updated some bits, but likely some other bits are lagging behind the copy you’ve been working on. IMO debian/README.source should merely point to the relevant sections of https://tails.boum.org/contribute/release_process/tails-installer/ (add HTML anchors if needed). I don’t care much about how exactly we solve this problem as long as you two agree with each other and we don’t have duplicate info that will inevitably diverge over time.

#18 Updated by anonym 2018-03-02 15:45:40

• Assignee deleted (anonym)
• % Done changed from 50 to 90
• QA Check changed from Dev Needed to Info Needed

intrigeri wrote:
> All these changes look good!
>
> Three more comments:
>
> The “Update debian/changelog” section could perhaps mention something about the common mistakes we’ve seen in the past, most notably:
>
> * Every Tails ticket ID must be Tails#NNNNN, not #NNNNN and definitely not Closes: #NNNNN
> * The raw data compiled by gbp dch must be edited to convey information that’s relevant and self-contained for a Debian audience (clearly our upstream commit messages are not written with this audience in mind). For example, the 5.0.4+dfsg-0tails1 changelog entry is pretty good, but things like “Apply awful hack to fix TailsBug #14755” are meaningless for a Debian audience.
>
> Feel free to copy’n’paste my text above and be done with it.

Done (with minor editing) in commit:ef16161244c8a5c7a49b494398ce304a093f199e.

> debian/README.source has a fork of part of this documentation. Ulrike has improved/updated some bits, but likely some other bits are lagging behind the copy you’ve been working on. IMO debian/README.source should merely point to the relevant sections of https://tails.boum.org/contribute/release_process/tails-installer/ (add HTML anchors if needed). I don’t care much about how exactly we solve this problem as long as you two agree with each other and we don’t have duplicate info that will inevitably diverge over time.

Ack. Ulrike, what do you want to do about this? Can’t you just like to our (online) instructions these days?

#19 Updated by Anonymous 2018-03-12 14:17:32

• QA Check deleted (Info Needed)

anonym wrote:
> intrigeri wrote:

> > debian/README.source has a fork of part of this documentation. Ulrike has improved/updated some bits, but likely some other bits are lagging behind the copy you’ve been working on. IMO debian/README.source should merely point to the relevant sections of https://tails.boum.org/contribute/release_process/tails-installer/ (add HTML anchors if needed). I don’t care much about how exactly we solve this problem as long as you two agree with each other and we don’t have duplicate info that will inevitably diverge over time.
>
> Ack. Ulrike, what do you want to do about this? Can’t you just like to our (online) instructions these days?

Sure ! Will do.

#20 Updated by Anonymous 2018-03-12 14:21:47

• Assignee set to anonym

I guess this ticket can be closed?

#21 Updated by bertagaz 2018-03-14 11:32:12

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

#22 Updated by intrigeri 2018-04-08 13:56:30

• blocked by deleted (Feature #13245: Core work 2018Q1: Foundations Team)

#23 Updated by intrigeri 2018-04-08 13:56:34

• blocks Feature #15139: Core work 2018Q2: Foundations Team added

#24 Updated by intrigeri 2018-04-10 07:02:01

• QA Check set to Ready for QA

#25 Updated by intrigeri 2018-04-13 11:32:34

• Assignee changed from anonym to intrigeri

#26 Updated by intrigeri 2018-04-14 07:11:22

• related to Bug #15533: Clarify the status of Tails Installer for Jessie added

#29 Updated by intrigeri 2018-04-14 07:16:11

• Assignee changed from intrigeri to anonym

I’ve fixed a few minor issues (see today’s commits that refs: <del><a class='issue tracker-1 status-3 priority-5 priority-default closed child' href='/code/issues/12152' title='Update tails-installer release process'>Bug #12152</a></del>) and am now happy with the result. Please review my fixes and close this ticket! :)

#30 Updated by anonym 2018-04-26 10:36:24

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