Project

General

Profile

Bug #12152

Update tails-installer release process

Added by u about 1 year ago. Updated 3 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Start date:
01/17/2017
Due date:
% Done:

0%

QA Check:
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
Blocks Tails - Feature #13245: Core work 2018Q1: Foundations Team Confirmed 06/29/2017

History

#1 Updated by u about 1 year ago

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

#3 Updated by intrigeri about 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 10 months ago

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

#5 Updated by intrigeri 9 months 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 8 months ago

#7 Updated by anonym 8 months ago

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

#8 Updated by anonym 5 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 5 months ago

#10 Updated by intrigeri 5 months ago

#11 Updated by anonym 3 months ago

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

#12 Updated by intrigeri 3 months ago

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

#13 Updated by intrigeri about 2 months ago

#14 Updated by intrigeri about 2 months ago

Also available in: Atom PDF