Hi!
(I tried to ask the question to Mike Perry on IRC but I am not sure that it was the best place to do so, also given that my proxy had connectivity issue yesterday. If someone have already answered me there, I apologies for wasting a little bit of your time, but I did not receive the reply.)
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?
Cheers,
Thus spake Jérémy Bobbio (lunar@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.
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@torproject.org):
Thus spake Jérémy Bobbio (lunar@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Jérémy Bobbio -
Mike Perry