Tails

#2 Updated by Anonymous 2015-11-26 03:41:25

I thought that it would be a good idea to set up a git repo on Alioth, for pkg-privacy-maintainers and there we would clone the existing repository. do you think this is a good idea?

Probably the cleanest way would be to split into upstream and packaging again.
On the Debian side, we would need to rename feature/jessie to master and not upload the tails/* branches.

Or just keep everything the same so that both repositories would have the exact same structure.

What do you think?

#3 Updated by intrigeri 2015-11-26 05:07:22

> I thought that it would be a good idea to set up a git repo on Alioth, for pkg-privacy-maintainers and there we would clone the existing repository. do you think this is a good idea?

At first glance yes, but I can’t think about it much before the implications are clarified (e.g. in terms of process adjustents and doc updates). I suggest you pick a doc-driven approach when you come back to in next year, so that we don’t jump to technical solutions before we are confident that they will actually fit well into the bigger picture :)

#5 Updated by Anonymous 2016-03-07 15:55:13

Here is a first idea:

Given I am a Debian contributor and part of pkg-privacy-maintainers
And I want to update the tails-installer package in Debian
Then I have 2 possibilities:
   I can simply pull the new upstream tag, and import it in the Debian packaging branch OR
   Given Tails developers already updated the package for Tails, I can pull directly from the tails/jessie branch and merge it into the debian/sid branch.
Those pulls imply that I add the Tails repository as git remote repository besides the Debian repository.
Then I create a debian/x.x tag following our documentation at https://tails.boum.org/contribute/release_process/tails-installer/
The debian/ specific tags will not be pushed to the Tails repository anymore if anybody else than intrigeri and me would take care of the packaging.

That would mean that the Debian repository does not need the master branch, only for comparing commits eventually.

I don’t think that there is a case in which Tails Developers would release a new upstream version without creating a new package for Tails right now. But I suppose that the idea of tails-installer in Debian is also to be able to use the Debian package and not create any Tails specific packages anymore at some point?

In this case only the first possibility ^ would apply, correct?

Concerning Ubuntu packages, in the future they will be pulled automatically from Debian whereas currently only intrigeri or me can upload them to the Ubuntu PPA. SO all tages related to ubuntu are not needed in the Debian packaging repository.

Same goes for Tails specific packaging, which is currently absolutely the same as the Debian package, except for the debian/changelog entries. Only Tails Developers need access to this.

For now I’ve pushed to the Alioth repository all branches and tags related to debian/sid, debian/experimental, debian-backports, debian/4, upstream/4.x, upstream/4, tails-installer_4*, pristine-tar and master.

I’d love to have some comments on this from intrigeri, because I am sure that I missed some details here :)

#9 Updated by Anonymous 2016-03-19 00:15:32

Correct.

#13 Updated by Anonymous 2016-05-25 13:21:30

This can indeed wait a bit.

To reframe the context: I’ve sorted out the packaging repository and imported the relevant branches to the Debian packaging repository already.

I’ve updated the debian/sid branch like this:

Vcs-Git: https://anonscm.debian.org/git/pkg-privacy/packages/tails-installer.git
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-privacy/packages/tails-installer.git

But this is not yet visible in the package tracker because there has not been a new version since I made that change.

This ticket is merely now about reviewing the documentation part for packaging Tails Installer.

#16 Updated by Anonymous 2016-07-25 07:33:31

intrigeri wrote:
> meta for u: this can (and actually should!) wait until you’re done with more pressing matters such as Feature #11109. But I’ve left this on my plate for too long so I’ll send it back to yours, and you can come back to it once DAVE is happily using our new mirror pool design! In other words: maybe it’s best if you don’t read this message right now ;)

Ack. I’ve tried to push Feature #11109 as far as possibly for now, so answering this now.

> > Given Tails developers already updated the package for Tails, I can pull directly
> > from the tails/jessie branch and merge it into the debian/sid branch.
> > Those pulls imply that I add the Tails repository as git remote repository besides the Debian repository.
> > Then I create a debian/x.x tag following our documentation at https://tails.boum.org/contribute/release_process/tails-installer/
> > The debian/ specific tags will not be pushed to the Tails repository anymore if
> > anybody else than intrigeri and me would take care of the packaging.
>
> OK. This makes lots of sense to me. There surely will be lots of details to fix later along the way, but we can’t guess everything from our current vantage point, so let’s go for it :)

ack.

> > That would mean that the Debian repository does not need the master branch, only for comparing commits eventually.
>
> Indeed.
>
> But the pristine-tar and upstream/* branches need to be shared between these two packaging repositories, as long as some people (Tails RM) do packaging in one repo, while other people (pkg-privacy) do packaging in another repo. Or, we just require Tails RM:s to join pkg-privacy and all packaging happens on the Alioth repo, and our own repo is only used for upstream work (and packaging of snapshots of topic branches).

I agree. It would be the easiest to have packaging happen only on Alioth.

> I think that’s the only question left open, before you can tackle the packaging doc update. I’m tempted to go the “all packaging work done on Alioth as part of pkg-privacy” way. We’ll need to check if anonym is fine with that. But it’ll be hard for him to reason about it without something more practical to see ⇒ I suggest you prepare a branch that updates the doc so he can comment on the actual effect this would have on his work. And worst case, if he doesn’t like it and we need to split Tails and Debian packaging over two repos, I think that most of the work done previously won’t be wasted :)

I’ll update the documentation then.

> > But I suppose that the idea of tails-installer in Debian is also to be able to use the Debian package and not create any Tails specific packages anymore at some point?
>
> I’d love to see this happen, but we’re not there yet. E.g. for now, Tails Installer’s release cycle is tight to Tails’ one, which can’t be the case if we pull it from Debian backports. So let’s keep assuming “that the latest upstream release has been imported into a Tails packaging branch” as documented, for now.

Agreed.

> > Concerning Ubuntu packages, in the future they will be pulled automatically from Debian […]
>
> I don’t understand what you mean here. Can you please clarify?

Well, for now, the Ubuntu uploads to the tails-team PPA can be made by me and people who have access to the Tails developers signing key. But at some point in time, we will not use the PPA anymore, but Ubuntu will include the tails-installer Debian package from the Debian repositories automatically (in a far future new stable version of Ubuntu). Right?

#17 Updated by intrigeri 2016-07-25 09:37:56

>> > Concerning Ubuntu packages, in the future they will be pulled automatically from Debian […]
>>
>> I don’t understand what you mean here. Can you please clarify?

> Well, for now, […]. But at some point in time, we will not use the PPA anymore, but Ubuntu will include the tails-installer Debian package from the Debian repositories automatically (in a far future new stable version of Ubuntu). Right?

I’m not aware of any such plan.

I haven’t seen new/updated info or reasoning that would make me change my mind on this topic, so for now I’m still of the opinion that we should not include Tails Installer in stable distros. I realize that I may be over-cautious though, and I am open to being proven wrong, i.e. to being shown that it’s actually doable to include it there, without messing too much with distros stable update rules. This could be done at any time by looking at the past (what if we had included Tails Installer in Wheezy? in Jessie? and in a couple years: in Stretch?).

Cheers!

#19 Updated by Anonymous 2016-10-27 08:43:42

What’s left to be done here:

• ask anonym if he’s fine with doing the packaging in alioth and as part of pkg-privacy
• update our documentation accordingly
• add a link to that doc in tails-installer packaging (if not done yet)

#25 Updated by intrigeri 2016-11-10 09:58:32

Today I feel sorry about my comment from yesterday. I should have waited until we can talk about it in person.

#26 Updated by anonym 2016-11-10 10:35:41

As an RM, I agree it would be super nice to have one less thing to do at release time. However, I expect there to be times when the RM needs a new tails-installer release ASAP (due to some issue detected late in the release process, or simply due to delays for a new needed feature to be merged) but the separate Debian package maintainer (i.e. u) is not available. So, as an RM I must be able to prepare such releases, and then upload them to Tails’ repo and install it from there (instead of from Debian’s repos). So as long as the release docs for tails-installer is kept fresh, we’re good.

A related discussion is of the frequency of upstream tails-installer releases vs translation imports. Until now we’ve basically released a new version every release, most of the time just pulling in new translations and shipping no new code. That probably made sense years ago, when a lot of translations were missing, but were added often. However, I think we can stop with that (and actually do the same for all other bundled deb:s) and hence get the most of “one less thing to do at release time [for the RM]”. IMHO it would be good enough if this happened once every freeze for a major Tails release — after all, that’s when we freeze the Debian APT state for the next ~12 weeks, and if we are to install a new tails-installer package from the Debian repos, it better be in there by then. :)

#27 Updated by intrigeri 2016-11-10 11:05:01

Hi!

anonym:
> As an RM, I agree it would be super nice to have one less thing to do at release time. However, I expect there to be times when the RM needs a new tails-installer release ASAP (due to some issue detected late in the release process, or simply due to delays for a new needed feature to be merged) but the separate Debian package maintainer (i.e. u) is not available. So, as an RM I must be able to prepare such releases, and then upload them to Tails’ repo and install it from there (instead of from Debian’s repos). So as long as the release docs for tails-installer is kept fresh, we’re good.

Right. Adding more bits: it’s basically the same for every other package we install from Debian, except that in this case the RM also plays the role of the upstream, and the packaging process is a bit more involved ⇒ I agree with the need for up-to-date docs to support this use case (AFAICT said doc is currently up-to-date, but it might need a refresh if the packaging canonical location moves to pkg-privacy Git space).

> A related discussion is of the frequency of upstream tails-installer releases vs translation imports. Until now we’ve basically released a new version every release, most of the time just pulling in new translations and shipping no new code. That probably made sense years ago, when a lot of translations were missing, but were added often. However, I think we can stop with that (and actually do the same for all other bundled deb:s) and hence get the most of “one less thing to do at release time [for the RM]”. IMHO it would be good enough if this happened once every freeze for a major Tails release — after all, that’s when we freeze the Debian APT state for the next ~12 weeks, and if we are to install a new tails-installer package from the Debian repos, it better be in there by then. :)

ACK. That’s cool, and valid both for the “RM releases + packages” and the “upstream developer releases + Debian maintainer packages” scenarios.
Now, I wonder if a better, and more flexible approach, would be to skip the release except if there’s something worth to put in it: even at freeze time for a major release, I suspect that sometimes it’s simply not worth it. Perhaps it’s too hard to encode what “if there’s something worth to put in it” means though, and your proposal is probably a good approximation, so let’s go with it.

#28 Updated by Anonymous 2016-11-10 11:48:59

intrigeri wrote:
> Today I feel sorry about my comment from yesterday. I should have waited until we can talk about it in person.

I’m glad you think about it a day later again, but there’s no need to feel sorry, don’t worry :)

#29 Updated by Anonymous 2016-11-10 11:56:50

intrigeri wrote:

> For now, we can simply put this ticket on hold, and focus on putting Tails Installer in a good shape in Debian: while doing the packaging work you can take notes that will be perfect input for updating the doc later :) [OT: BTW this package needs to be dropped from Stretch at some point, e.g. after the hard freeze. I’m not sure if we have a ticket for that.]

It’s on my todo list to update the package and to create one for the latest Ubuntu stable PPA.

#30 Updated by Anonymous 2016-11-10 12:54:32

intrigeri:
> anonym:
> > As an RM, I agree it would be super nice to have one less thing to do at release time. However, I expect there to be times when the RM needs a new tails-installer release ASAP (due to some issue detected late in the release process, or simply due to delays for a new needed feature to be merged) but the separate Debian package maintainer (i.e. u) is not available. So, as an RM I must be able to prepare such releases, and then upload them to Tails’ repo and install it from there (instead of from Debian’s repos). So as long as the release docs for tails-installer is kept fresh, we’re good.

ACK.

> Right. Adding more bits: it’s basically the same for every other package we install from Debian, except that in this case the RM also plays the role of the upstream, and the packaging process is a bit more involved ⇒ I agree with the need for up-to-date docs to support this use case (AFAICT said doc is currently up-to-date, but it might need a refresh if the packaging canonical location moves to pkg-privacy Git space).

ACK.

I’m also in favor of being able to have Tails specific packages, just in case of an emergency release which should be in Tails.

> > A related discussion is of the frequency of upstream tails-installer releases vs translation imports. Until now we’ve basically released a new version every release, most of the time just pulling in new translations and shipping no new code. That probably made sense years ago, when a lot of translations were missing, but were added often. However, I think we can stop with that (and actually do the same for all other bundled deb:s) and hence get the most of “one less thing to do at release time [for the RM]”. IMHO it would be good enough if this happened once every freeze for a major Tails release — after all, that’s when we freeze the Debian APT state for the next ~12 weeks, and if we are to install a new tails-installer package from the Debian repos, it better be in there by then. :)
>
> ACK. That’s cool, and valid both for the “RM releases + packages” and the “upstream developer releases + Debian maintainer packages” scenarios.
> Now, I wonder if a better, and more flexible approach, would be to skip the release except if there’s something worth to put in it: even at freeze time for a major release, I suspect that sometimes it’s simply not worth it. Perhaps it’s too hard to encode what “if there’s something worth to put in it” means though, and your proposal is probably a good approximation, so let’s go with it.

ACK. I think that this was pretty much what the initial proposal was really about: skip the release unless there is something worth to put into it.

I think if upstream is capable of sending me an email whenever there should be an update, that would ease the process for me to prepare a Debian package early enough. I don’t know if there’s another way of being aware of changes upstream. With upstreams on Github I get email notifications for example.

Still, it might be good if anonym also had access to pkg-privacy, but it seems that it’s not a requirement to make the proposal work out. The only thing which is really shared between Tails packaging and Debian packaging would be the pristine-tar branch.

#31 Updated by sajolida 2016-11-10 15:55:59

Sorry if I’m jumping in the discussion like this but I’m trying to follow and understand the workflows and concerns (and maybe learn a bit of free software culture on the way).

I understand that, on top of merely preparing the packages from the source code, there’s a bunch of additional work related to preparing releases of Tails Installer, like pulling translations. But then how does this relates with what would be the maintenance of Tails Installer itself, let’s say merging kurono’s work when ready, deciding which tickets to prioritize, making sure Feature #11569 is dealt with, etc. Not writing the code in itself but well… maintaining the whole stuff. Would this be part of RM, part of the foundations team, or part of #11343?

Until now I understand that the foundation teams is doing both (maintaining the code base and preparing the packages). In your last comment u, the way you said “upstream” let me believe that you were only concieving your work as preparing the packages from a code base that would be handed out to you. Is that right? But maybe we should also clarify who’s “upstream”? the RM or the foundations team? Is it better the split the two responsabilities or to have the same people take care of both?

But maybe I’m not getting it what I’m saying doesn’t make any sense :)

#35 Updated by intrigeri 2017-01-24 14:53:04

u wrote:
> sajolida wrote:
> > I understand that, on top of merely preparing the packages from the source code, there’s a bunch of additional work related to preparing releases of Tails Installer, like pulling translations. But then how does this relates with what would be the maintenance of Tails Installer itself, let’s say merging kurono’s work when ready, deciding which tickets to prioritize, making sure Feature #11569 is dealt with, etc. Not writing the code in itself but well… maintaining the whole stuff. Would this be part of RM, part of the foundations team, or part of #11343?
>
> Currently this is part of the work done by the RM as far as I know.

To clarify, I think that’s partly on the RM’s plate (reviewing and merging), and the Foundations Team’s plate (everything else).