Discuss move to Firefox ESR
On https://blog.torproject.org/blog/new-tor-browser-bundles-16 I noticed the following comment:
Why not using Firefox ESR? https://www.mozilla.org/en-US/firefox/organizations/faq/
Less often new Firefox "features" which often have a detrimental effect on anonymity.
I decided to copy it here so we can discuss the implications of this choice. Keep in mind that ESR's will still get security updates.
Activity
There is a thread about this on tor-dev. Here's my reasoning not to move to ESR: https://lists.torproject.org/pipermail/tor-dev/2012-April/003477.html
I'm not 100% set in my decision. We are getting a lot of noise and instability from rapid Firefox releases and code changes... But I also think allowing those to accumulate into a huge pile every 6-9 months is not the right solution to that problem, either. I also worry it will mean our patches will be even more ignored.
Trac:
Cc: N/A to Sebastian, lunarReplying to mikeperry:
There is a thread about this on tor-dev. Here's my reasoning not to move to ESR: https://lists.torproject.org/pipermail/tor-dev/2012-April/003477.html
I'm not 100% set in my decision. We are getting a lot of noise and instability from rapid Firefox releases and code changes... But I also think allowing those to accumulate into a huge pile every 6-9 months is not the right solution to that problem, either. I also worry it will mean our patches will be even more ignored. I don't think the release frequency is the issue here, since ESR still releases security updates. It's more that the regular releases might add new de-anonymizing features.
We could also do both: use ESR for the standard TBB to provide a more stable experience for the regular joe and, next to that, offer regular release FF or even beta FF with our alpha-version TBB.
-
Hrmm.. Using rapid release only for alpha might not be a terrible plan. I still think we should focus on improving our testing procedures rather than focus on effectively supporting two browsers. I guess maybe I should defer to Erinn and Sebastian for the decision on this one. Do our patches apply cleanly to ESR right now?
-
cypherpunks: I've thought more about this, and I think you're right. From a best practice perspective, we should be doing ESR for stable, and rapid release for alpha (though we better hope we have enough testers running alpha to find serious bugs in time). I'm waiting on a response from Sebastian+Erinn to see how painful this will be for them to adjust.
In other news, the esr releases all appear to be in the usual release dir. I just didn't see the updates to 10.0esr initially because they're out of order. https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/
Oh, interesting. Looks like esr releases don't get mirrored to releases.mozilla.org, but good to know they're out there.
When looking just at the build process and what we'd need to do to support esr for stable releases and regular for alphas, that should be fairly easy to do. I do worry that it'd be a higher burden on you tho, because you'd get to fix up to sets of patches rather than one. Another question is what happens when there's a fix in a newer firefox version that isn't deemed high impact enough by mozilla to be backported to esr, do we backport it ourselves? How do we keep track of such things?
If we can answer those questions to a sane extend, there shouldn't be much stopping us from following that scheme.
-
It will be a higher burden on me. But my burden is already well over 100% capacity anyways. Making it marginally higher isn't going to change much. It just means we'll have to tolerate other things getting done slower or not done at all as the tradeoff, and we'll be able to promise fewer things to sponsors directly from me. I think having better development processes is worth that tradeoff, given the recent series of regressions and other issues we've had.
Right now I'm mostly able to keep up with 'critical' and above level bugs though, and still get some 'major' level ones done too. If I lose the ability to complete 'major' level bugs entirely, we can revisit this.
I'll create a separate ticket for rebasing my patches to the latest 10.0ESR and seeing how that works out.
Replying to mikeperry:
cypherpunks: I've thought more about this, and I think you're right. From a best practice perspective, we should be doing ESR for stable, and rapid release for alpha
Yay. That does seem like the wise thing to do.
-
FYI: Ticket #5790 (closed) is for my backport rebase attempt. I hope to get to it this month before FF13 drops.
Trac:
Cc: Sebastian, lunar to Sebastian, lunar, g.koppen@jondos.deI don't mind this idea in theory, especially for stable releases. The release process is a lot less time intensive than it used to be and I would expect most of the difficult overhead to be on your end, Mike (keeping up with all of the releases, updating patches, etc.) I think it's a fine idea to try it out, although I share Sebastian's concerns about backporting fixes etc. But like I said, I'm happy to try it out and readjust as needed.
The only changes I will need to make on my side are getting a lot more disk space for the build machines. They are currently nearly at capacity (except for the OS X one) and don't have enough space to build another Firefox. That should be pretty fixable though. There's a ticket for the Windows VM already and I will make one for the Linux VM now. (I should note that this is also important for buildbot purposes, because it is not currently possible to use those VMs for anything but official builds because of space isses.)
(for some reason I'm not getting updates on my own ticket)
Trac:
Cc: Sebastian, lunar, g.koppen@jondos.de to Sebastian, lunar, g.koppen@jondos.de, ShondoitTrac:
Cc: Sebastian, lunar, g.koppen@jondos.de, Shondoit to Sebastian, lunar, g.koppen@jondos.de, Shondoit, tails@boum.orgmentioned in issue #5790 (closed)