The workflows we use for Tor Browser are kinda peculiar.

When you manage a fork, you need a strategy to stay updated with upstream. We create a new branch for every new Firefox release and cherry-pick our previous commits on top of it.

The advantage over merging is that our patches always stay in a single and compact block of commits. So, it is trivial to tell our commits from upstream, and users can easily verify we do not modify Firefox outside those commits (we keep the commit hashes of gecko-dev, the official GitHub mirror of Mozilla's mercurial repositories).

There are also disadvantages: keeping fewer commits helps with this workflow. Therefore, our commits have a meaning of “feature”, not of “change”. Thus, we constantly update them, and the history of a patch becomes hard to follow.

And most importantly, this workflow requires frequent rebases, with the risk of losing some changes. To mitigate it, every new branch goes through a review process before we switch to it.

The main tools we use are git range-diff to check single commits and “diff-of-diffs” to check the patch set as a whole. … [Leggi il resto]

Ten days ago, Mullvad released Mullvad Browser. I was involved in its development, being part of the applications team at the Tor Project.

So, I would like to use this occasion to describe how we maintain Tor Browser and the similarities with Mullvad Browser.

Firefox ESR

Tor Browser is a fork of Firefox. However, we are a small team, and we cannot stay on pass with the rapid release channel of Mozilla.

Instead, our starting point is the extended support release, the version geared towards enterprises.

It is not an old Firefox, but a channel Mozilla actively supports for about one year. Like the rapid release, it receives monthly updates, typically only with security patches. It rarely receives new features.

This is an enormous advantage because we can quickly update Tor Browser without auditing the changes. Moreover, these few changes are unlikely to create conflicts to be manually merged and reviewed carefully. … [Leggi il resto]

Tempo fa, negli obbiettivi di Agosto avevo parlato di un certo “VDFN System”.

Alla fine non ho avuto il tempo fisico per lavorarci, però ci ho pensato un po’.

Sono giunto alla conclusione di rimandare il progetto a tempo indeterminato se non proprio eliminarlo in favore di un framework già pronto.

Voglio infatti approfondire la programmazione che si basa sul paradigma MVC: Modello - Vista - Controllore (guardate Wikipedia per ulteriori informazioni).

Ho trovato due framwork che mi vanno particolarmente a genio: CakePHP che è molto completo e ho già iniziato a studiare, oppure TinyMVC che è molto molto più leggero ma non mi darebbe “vincoli”.