[tbb-dev] Nightly rebase experiment proposal

Nicolas Vigier boklm at mars-attacks.org
Tue Nov 21 20:44:56 UTC 2017


On Tue, 21 Nov 2017, Arthur D. Edelstein wrote:

> * We'll need to continuously monitor the mozilla codebase for new
> features that could harm privacy. That's potentially difficult, but by
> focusing on Mozilla's current work, we can hopefully stop patches that
> affect privacy before they land.

From your list it seems to me the most challenging part will be to
continuously monitor the mozilla changes and be able to find workarounds
for all issues in time before each release. But maybe the closer
collaboration with Mozilla can help with this.

> 
> Here's how I envision the new rebase process:
> 
> * An automated script rebases all tor browser patches every night
> against mozilla-central, mozilla-beta, mozilla-stable and mozilla-esr.
> An email alert will be sent if the rebase of any patch fails. (I have
> a prototype script that does the basic rebasing -- it found that
> ~40/140 patches from our ESR-52 branch could be auto-rebased onto
> mozilla-central without any intervention.)
> * Any failed patches will need to be manually fixed up promptly so
> that the automated rebase can resume.
> * Diagnostic Tor Browser bundles will be built against the latest
> rebase branches. We can also run regression tests.
> 
> So how do we ramp up this experiment?
> 
> 1. 2018-1-1 to 2017-2-22: Rebase tor-browser.git patches manually on
> top of Firefox 59-beta. (We have to do this anyway.)
> 2. 2017-2-22 to 2018-3-13: Activate a script that rebases Tor Browser
> patches nightly onto mozilla-(central, beta, stable, esr).
> 3. 2018-03-13 to 2018-05-07: Create nightly Tor Browser bundle builds
> based on nightly rebases.
> 
> At this point, we can evaluate whether we would like to transition to
> releasing Tor Browser alphas based on the mozilla-beta branch.
> Switching Tor Browser stable to mozilla-stable can happen sometime
> after that.
> 
> How does this sound? Interested to hear what you think.

This looks like a good plan to me.

If we go with that plan I think we should also check whether a git
branch is still the best way to maintain our patches. I have not been
thinking about that a lot yet, but maybe an alternative could be to use
quilt [1] or some similar tool to manage patch series. So we could store
a quilt patch series as a directory somewhere into tor-browser-build.git,
which should make it easier to apply our patches on different firefox
trees.

[1]: https://en.wikipedia.org/wiki/Quilt_(software)

Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20171121/5c33df42/attachment.sig>


More information about the tbb-dev mailing list