Re: [Tails-dev] about the maintenance of I2P in Tails

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] about the maintenance of I2P in Tails
Hi,

I've thought a bit about all this. Thanks for all the useful input,
it helped me design a plan that I like.

Note that, on the long run, we'll want to import *all* external
packages we use into our own APT repository at freeze time (and,
likely, in the beginning of a release cycle too). This is a must for
enforceable freezes, for reproducible builds, and to be able to
distribute the source code of the binary packages we ship in Tails.
So, I don't think it's worth it to make things more complicated on
killyourtv's side than they need to be.

Also, I don't think we want to distribute more binary packages from
3rd-party repositories in Tails, without distributing the sources.

To end with, it seems critical to me to avoid having to synchronize
with killyourtv at freeze time.

I think the best way to handle it is:

  * killyourtv maintains a Tails-experimental suite in their APT
    repository.
  * Optional: we patch auto/scripts/tails-custom-apt-sources to
    include this suite when building from our experimental branch.
    This makes the next step easier.
  * When s/he wants Tails to get a newer version of I2P, killyourtv
    uploads it to their Tails-experimental APT suite and asks for
    a review'n'merge. Most of the times, no change is needed in Tails
    source code, but when it's needed, then the review'n'merge request
    must include a feature/i2p-$version branch.
  * After successful review, the reviewer pulls the new packages into
    *our* APT repository (in the devel or stable suite, depending on
    whether we're preparing a major or point-release), probably thanks
    to reprepro's pull feature.
  * At freeze time, the release manager does just the same as usual
    (merge our devel suite into our testing one).
  * Eventually, the I2P packages shipped in Tails $VERSION land into
    the $VERSION APT suite in our repository.


I think this aligns perfectly with how we'll be handling external APT
repositories (such as Debian's and Tor project's) on the long run, and
could even be a nice test-bed for the tools and processes we'll need
when we come to it.

Thoughts?

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc