{{toc}}

Rationale

• Git becomes sluggish, mainly due to binary and source Debian packages we’ve been storing in Git.
• We’ve never taken advantage of mixing website with sources, so we only experience the disadvantages of it.

Our plan

New Git repositories

… with history imported and rewritten to filter out parts that were splitted out:

• tails-live.git: the Tails source code we feed live-build with
• tails-website.git: the source of this website (i.e. more or less what is currently in wiki/src

APT repository

Current state: implemented.

We have imported binary and source packages from our Git repository for past releases (completed on 2012-11-14).

Let’s say the not-merged-yet branches will see their packages imported as they are worked on.

.mrconfig or Git submodules

A few teams, such as the debian-installer and Debian Perl ones, that use many Git repositories (thousands, in case of the latter), have been successfully using mr to make an initial checkout easier for new contributors, and generally making it easier to deal with a lot of repositories (mass-update, etc.). We could do the same, starting with maintaining and publishing a .mrconfig file.

Additional custom repositories we use and may want to include in this .mrconfig: whisperback, live-boot, live-config, vidalia, htp, tails-greeter.

We probably should ship two mrconfig files: one that uses anonymous git:// read-only remotes, the other that uses ssh:// read-write remotes.

OTOH, Git submodules allow to do basically the same thing, but also to make it clear what version of these other repositories a given Git branch (in the main repo) needs.

Ressources:

• d-i help page
• pkg-perl help page

Next things to do

Now that the APT repository (Feature #5351) is setup, and old packages imported, see sub-tickets for the next steps.