Project

General

Profile

Feature #10666

Feature #7544: Have a multiplatform Installer

Feature #8550: Make Tails Installer work on Windows

Feature #8558: Study feasibility of porting Tails Installer to Windows

Sort out packaging Git repo for Tails Installer in Debian/Ubuntu

Added by intrigeri almost 4 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Installation
Target version:
Start date:
11/25/2015
Due date:
% Done:

100%

Feature Branch:
451f:feature/10666+tails-installer-doc
Type of work:
Debian
Blueprint:
Starter:
Affected tool:
Installer

Description

On the one hand the package is team maintained. On the other hand, Vcs-* fields point to a repository where nobody on the packaging team (but intrigeri) has write access to. This is inconsistent, and won't work in practice.

History

#2 Updated by u almost 4 years ago

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 almost 4 years ago

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

#4 Updated by u almost 4 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

I've initiated an empty repository in pkg-privacy-maintainers on Alioth but not copied any files there yet. I'll work on it the way you suggested in two months from now.

#5 Updated by u over 3 years ago

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

#6 Updated by u over 3 years ago

  • Assignee changed from u to intrigeri
  • % Done changed from 10 to 20
  • QA Check set to Info Needed

#7 Updated by intrigeri over 3 years ago

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

(No way I can handle this today.)

#8 Updated by intrigeri over 3 years ago

  • Assignee changed from intrigeri to u
  • QA Check deleted (Info Needed)

If I got it right, this boils down to "do Tails specific packaging in the Tails-specific Git repo, and do Debian packaging in the pkg-privacy team's Git repo on Alioth". Sounds good, go ahead with updating the doc :)

#9 Updated by u over 3 years ago

Correct.

#10 Updated by u over 3 years ago

  • Assignee changed from u to intrigeri
  • QA Check set to Ready for QA
  • Feature Branch set to 451f:tails/tails-installer.mdwn

I've slightly modified the instructions.

#11 Updated by intrigeri over 3 years ago

  • Target version changed from Tails_2.3 to Tails_2.4

#12 Updated by intrigeri over 3 years ago

  • Target version changed from Tails_2.4 to Tails_2.5

Postponing again, sorry! Anyway, I guess that you have forgotten part of the context just like me, and we're busy with other matters right now, so this can wait a bit more (e.g. until after we've deployed the new mirror pool and shipped Icedove autoconfig wizard in 2.4).

#13 Updated by u over 3 years ago

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.

#14 Updated by intrigeri over 3 years ago

  • Feature Branch changed from 451f:tails/tails-installer.mdwn to 451f:feature/10666+tails-installer-doc

#15 Updated by intrigeri over 3 years ago

  • Assignee changed from intrigeri to u
  • Target version changed from Tails_2.5 to Tails_2.6
  • QA Check changed from Ready for QA to Dev Needed

Hi!

meta for u: this can (and actually should!) wait until you're done with more pressing matters such as #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 ;)

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

Yes, modulo this is not just a Git merge (one needs to create the .orig repacked tarball).

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

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

What do you think?

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.

Agreed.

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.

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

Right.

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?

#16 Updated by u over 3 years ago

intrigeri wrote:

meta for u: this can (and actually should!) wait until you're done with more pressing matters such as #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 #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 over 3 years ago

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!

#18 Updated by anonym about 3 years ago

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

#19 Updated by u about 3 years ago

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)

#20 Updated by u about 3 years ago

  • Target version changed from Tails_2.7 to Tails_2.9.1

#21 Updated by u about 3 years ago

  • QA Check changed from Dev Needed to Info Needed

After talking to anonym, it appears that it's unclear why tails-installer should continue to be part of the Tails release process at all, because it's now not a Tails-only package anymore.

9/10 releases of tails-installer only contained fresh translations.

So here's a better plan:
When working on new features or bugfixes, a new upstream version should be released by the person doing or reviewing these modifications.
The packaging would happen in Debian only and be done by the maintainer.
Tails would use the official Debian package.

If we agree, and I do, then the documentation should be moved/renamed and the packaging part should go into the Debian packaging.

#22 Updated by u about 3 years ago

  • Assignee changed from u to intrigeri

Assigning to intrigeri for comment.

#24 Updated by intrigeri about 3 years ago

  • Assignee changed from intrigeri to u

Hi!

After talking to anonym, it appears that it's unclear why tails-installer should continue to be part of the Tails release process at all, because it's now not a Tails-only package anymore.

Yes! As I think both of you know, I do like the idea of moving the packaging of Tails Installer outside of the Tails release process… at the very least, in terms of timing. I've been a long-term supporter of uploading our stuff to Debian and then taking it from there, for various reasons :)

So here's a better plan:
When working on new features or bugfixes, a new upstream version should be released by the person doing or reviewing these modifications.

ACK!

The packaging would happen in Debian only and be done by the maintainer.

I think that's the only question to which I see no obvious answer with the data I have in hand: who's responsible to make this happen routinely? So far, the RM has been; as I suggested in #10666#note-15, we could very well go on like this, except that the RM would do the packaging as part of pkg-privacy (and the rest of your proposal still works fine, which is great!). If I got it right, this proposal formalizes the fact that the packaging work is done by the maintainer, that is u. Unless that's done, then any bugfixes, translation updates, new features we might have developed won't flow into next Tails release. FTR I would love to see this happen. Still, I have some concerns due to how things have worked so far, in practice, in this area. Perhaps I'm being overly cautious (this would not exactly be news ;) but from my vantage point, what I see is:

  • having the packaging work on the RM's plate is proven to work: we've been doing it for years, and aside of the extra work load for the RM, so far it has been a truly good way to get packaging of new upstream code done routinely; if the RM was doing this as part of pkg-privacy, then things would not change for the RM, and all it would take to get our improvements into Tails release is one sponsored upload; granted, it's desirable that things do change for the RM, i.e. that they get one less thing to do during their shift;
  • so far, you've been (understandably!) too busy to take much care of tails-installer in Debian: e.g. there's been no upload since January, one bug has been tagged pending since February, and there's a bug report unanswered since March. Don't get me wrong: my point is not to show that you're doing the job badly -- you've been prioritizing things the best you could, and it makes totally sense to me that this was lower priority (I even explicitly encouraged you on this very ticket to postpone it until other more pressing matters were handled). Most of these non-handled things are no big deal, and if things had gone too bad I do hope that one of our pkg-privacy team-mates would have given a hand. I'm only listing these facts as they are the only data we have, that can be used to evaluate the viability of this proposal at this point, and I want to be extra-careful not to over-commit anyone on our team :)

You did explain in #11343#note-11 why things are as they are, and I think I understand this situation quite well. From what I've read there, and from what I've seen happen in practice, it looks like your proposal can't work smoothly until #11343 is resolved. Has anything changed substantially since #11343#note-11, that makes this proposal viable even if #11343 is not addressed?

If yes: cool! Let's go with your plan, and deal with #11343 later! 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.]

If not: that's perfectly fine as well, as far as this ticket is concerned. In which case, I propose that we go with your plan, except that until #11343 is fully resolved (i.e. whatever is needed for you to have time to keep up with things on this topic, is done), the RM is responsible for doing the packaging as part of pkg-privacy. The total amount of work for them will be the same, and the work we have to do on the Debian side will be lower, so that's already progress.

What do you think?

Tails would use the official Debian package.

ACK!

Cheers!

#25 Updated by intrigeri about 3 years ago

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 about 3 years ago

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 about 3 years ago

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 u about 3 years ago

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 u about 3 years ago

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 u about 3 years ago

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 about 3 years ago

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 #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 :)

#32 Updated by u almost 3 years ago

  • QA Check deleted (Info Needed)

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

Until now I understand that the foundation teams is doing both (maintaining the code base and preparing the packages).

Currently the RM is preparing custom packages for every Tails release after having pulled the translations. Now our proposal is to skip creating these custom packages everytime and instead focus on upstream work (done by kurono for example), then merging it and releasing a package only when new features have been put into the package. And then I will update the Debian package in Debian - and Tails can install Tails installer from Debian.

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?

Correct. Unless I'm supposed to work on any part of the code - which can sometimes happen - but this is considered as being upstream work.

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?

I don't think there is anything to clarify, at least not from my point of view. Upstream = Tails developers (intrigeri, anonym, kurono and me have been working on this package in the past - and maybe also others I don't know about).

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

I hope it makes more sense now.

#33 Updated by anonym almost 3 years ago

  • Target version changed from Tails_2.9.1 to Tails 2.10

#34 Updated by u almost 3 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (u)
  • % Done changed from 20 to 100

I think we can close this ticket. anonym has joined Debian's pkg-privacy team and he can now push there as part of the RM process. He also updated the corresponding release doc. A last remaining question might be if updating tails-installer at every release is still necessary. I'm creating another ticket for this as this one has a different scope.

#35 Updated by intrigeri almost 3 years ago

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 #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).

Also available in: Atom PDF