Project

General

Profile

Bug #12152

Update tails-installer release process

Added by u over 1 year ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
Installation
Target version:
Start date:
01/17/2017
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
Type of work:
Contributors documentation
Blueprint:
Starter:
Affected tool:
Installer

Description

In #8549 we discussed that updating tails-installer for every Tails release might now not be necessary anymore. I think we still need to update the RM release process and documentation with this new information.
Maybe we also need to define how it will happen instead?
Or do we simply maintain things as they are currently - that is now the RM can push to pkg-privacy? Should bertagaz also be added to pkg-privacy then?


Related issues

Related to Tails - Feature #8549: Have Tails Installer in Debian and Ubuntu Resolved 01/06/2015
Related to Tails - Bug #15533: Clarify the status of Tails Installer for Jessie Resolved 04/14/2018
Blocks Tails - Feature #15139: Core work 2018Q2: Foundations Team Confirmed 01/01/2018

Associated revisions

Revision 90f77b5d (diff)
Added by intrigeri 2 months ago

Fix phrasing (refs: #12152)

Revision 34f830a8 (diff)
Added by intrigeri 2 months ago

Salvage updates from src:tails-installer's debian/README.source (refs: #12152)

That file was deleted to avoid duplication but some of its improvements
were lost in the process.

Revision efa41781 (diff)
Added by intrigeri 2 months ago

Fix distro name (refs: #12152)

Revision 4da64ee0 (diff)
Added by intrigeri 2 months ago

Drop Ubuntu codenames that we don't manage to maintain (refs: #12152)

Instead, link to a place that has up-to-date info.

Revision 70b3a7ef (diff)
Added by intrigeri 2 months ago

Update a few distro codenames: Jessie → Stretch (refs: #12152)

History

#1 Updated by u over 1 year ago

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

#3 Updated by intrigeri over 1 year ago

  • 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 #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 #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 #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 about 1 year ago

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

#5 Updated by intrigeri about 1 year ago

  • 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 12 months ago

#7 Updated by anonym 12 months ago

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

#8 Updated by anonym 9 months ago

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

I started a bit on this on #8860 (in the feature/8860-tails-installer-improvements branch). From #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 9 months ago

#10 Updated by intrigeri 9 months ago

#11 Updated by anonym 7 months ago

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

#12 Updated by intrigeri 6 months ago

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

#13 Updated by intrigeri 6 months ago

#14 Updated by intrigeri 6 months ago

#15 Updated by anonym 4 months ago

  • Priority changed from Normal to Elevated

#16 Updated by anonym 4 months ago

  • 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 #8860 (in the feature/8860-tails-installer-improvements branch). From #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 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...

Right... in Debian. Done in 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 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 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 c47accdd0ad95af472654497972b194ec0d07bf7.

#17 Updated by intrigeri 4 months ago

  • 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 Tails#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 #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 4 months ago

  • Assignee changed from anonym to u
  • % 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 Tails#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 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 u 3 months ago

  • 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 u 3 months ago

  • Assignee changed from u to anonym

I guess this ticket can be closed?

#21 Updated by bertagaz 3 months ago

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

#22 Updated by intrigeri 2 months ago

#23 Updated by intrigeri 2 months ago

#24 Updated by intrigeri 2 months ago

  • QA Check set to Ready for QA

#25 Updated by intrigeri 2 months ago

  • Assignee changed from anonym to intrigeri

#26 Updated by intrigeri 2 months ago

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

#27 Updated by intrigeri 2 months ago

intrigeri wrote:

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 #14650#note-22). I think it should mention stretch-backports as well.

Filed #15533 about this problem.

#28 Updated by intrigeri 2 months ago

u wrote:

anonym wrote:

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

Sure ! Will do.

I've salvaged the updates from src:tails-installer's debian/README.source (34f830a83b0a75616656b8a7226eb670221bece6) that got lost in the process.

#29 Updated by intrigeri 2 months ago

  • Assignee changed from intrigeri to anonym

I've fixed a few minor issues (see today's commits that refs: #12152) and am now happy with the result. Please review my fixes and close this ticket! :)

#30 Updated by anonym about 2 months ago

  • 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

Also available in: Atom PDF