[tor-dev] TorBrowser and Firefox ESR

[Mike Perry]

I'm pretty sure I've been convinced to at least try out using ESR for
TBB-stable, while *also* using Rapid Release for TBB-alpha.

Maintaining both browser branches is going to come at the cost of me
doing other stuff, but it is probably worth it. See
https://trac.torproject.org/projects/tor/ticket/5737 for details.

However, we're also going to need to make sure our Volunteer QA team is
committed to testing the alpha builds regularly, or we'll still be
accumulating all of the chaos and pain of umpteen Rapid Release updates
over 9 months of the ESR cycle, and end up buried in regressions
all hitting us all at once when we update ESR major versions.

Add yourself to Cc on
https://trac.torproject.org/projects/tor/ticket/3846 to be informed of
details as the volunteer QA plan develops.

Thus spake Mike Perry (mikeperry at torproject.org):

> Thus spake Jérémy Bobbio (lunar at debian.org):
> 
> > It looks like Firefox maintainers in Debian have decided to ship
> > Extended Support Releases in the upcoming Wheezy release.
> > 
> > This made me wonder if ESR changed any plans concerning TorBrowser. Will
> > Tor Browser Bundle keep following upstream "personal use" releases or
> > switch to ESR?
> 
> I am conflicted about this. On the one hand, ESR would appear to make
> our lives easier, especially short term. On the other, I suspect that's
> mostly an illusion long term, and any issues we have with rapid release
> should be addressed by improving our dev and build processes.
> 
> The main advantages of tracking rapid release come in the form of
> Mozilla actually able to more easily work with our patches and also
> giving us the opportunity to communicate issues earlier as features
> appear and solidify.
> 
> The disadvantages of tracking rapid release come in the form of build
> overhead, periodic patch rebasing, and scrambling to review new features
> for fingerprinting issues.
> 
> However, it's not like if we don't track rapid release, we'll suddenly
> find the tor browser bug queue manageable. We're going to drown in
> browser bugs no matter what, I think. I also don't think the number of
> builds we'll need to do will substantially change. So far, there has not
> been a rapid release that did not also contain security fixes. I assume
> that means we'll have to do just as many ESR-based TBB builds for point
> releases as rapid release-based TBB builds.
> 
> Since we're doomed either way with our current dev capacity, I think we
> should choose the option that gives us the best chance of getting help
> from Mozilla.
> 
> Therefore, my inclination is to keep trying to track rapid release. 
> 
> -- 
> Mike Perry



> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20120506/daff7ece/attachment-0001.pgp>