tbb-dev August 2015

tbb-dev@lists.torproject.org

2 participants
3 discussions

Using topic branches for Tor Browser patches
by Nicolas Vigier 14 Dec '15

14 Dec '15

Hello, Currently on tor-browser.git, each Tor Browser release has a single branch that includes all our patches. This is simple, however it makes it difficult to test each patch individually, and see which patch is responsible for which test failure. For instance, the patch to add preference overrides causes many tests to fail, probably because many tests don't expect the default preferences to change: 31.7.0esr pass all tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5bbe47119ac0 31.7.0esr + preference overrides patch fails many tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fdc349fbbf5f After discussing about this quickly with intrigeri last week, I have been thinking about a different way to organize the patches: maybe we could use one branch for each topic, and merge all those branches in a single branch when we prepare the release. The naming of the branches could be: - ${firefox_version}/base: the commit for the firefox version we are using. - ${firefox_version}/${topic_name}: A branch containing patch(es) on a specific topic. $topic_name can be a bug number and/or a short description. We can submit those branches to Mozilla Try to see if they break some unit tests. - ${firefox_version}/${tbb_version}/${topic_name}: The same as the previous one, but for a topic that we only want to include in a specific Tor Browser version. - tor-browser-${firefox_version}-${tbb_version}-1: The branch that we use to build Tor Browser. This branch is based on ${firefox_version}/base, and includes merges of all branches matching ${firefox_version}/[^/]* or ${firefox_version}/${tbb_version}/[^/]*. As an exemple, I have converted a few patches from tor-browser-31.7.0esr-4.5-1 to this new naming in this git repository: https://github.com/boklm/gecko-dev/branches/all With all topic branches merged to this tor-browser-31.7.0esr-4.5-1 branch: https://github.com/boklm/gecko-dev/commits/tor-browser-31.7.0esr-4.5-1 I also started submitting some of them to Mozilla Try: 31.7.0esr/2874-Block-Components.interfaces-from-content: https://treeherder.mozilla.org/#/jobs?repo=try&revision=91cd13cf0ac7 (some mochitest tests failing) 31.7.0esr/2950-Make-Permissions-Manager-memory-only: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3f8cb0c1984e (tbb-tests/browser_tor_bug2950.js failing) 31.7.0esr/2949-Make-Intermediate-Cert-Store-memory-only: https://treeherder.mozilla.org/#/jobs?repo=try&revision=139538724d04 (no test failing) 31.7.0esr/3547-Block-all-plugins-except-flash: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c75fb4685994 (some xpcshell, mochitest, mochitest-chrome, reftest failing) 31.7.0esr/3229-Make-content-pref-service-memory-only-clearable: https://treeherder.mozilla.org/#/jobs?repo=try&revision=344873ae1513 (1 xpcshell test failing) 31.7.0esr/TB2-Provide-an-observer-event-to-close-persistent-connections: https://treeherder.mozilla.org/#/jobs?repo=try&revision=93af45d5111a (no test failing) 31.7.0esr/2875-Limit-device-and-system-specific-CSS-Media-Queries: https://treeherder.mozilla.org/#/jobs?repo=try&revision=32244f089736 (still running at the moment) 31.7.0esr/2872-Limit-the-number-of-fonts-per-document: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4abfb45bba86 (still running at the moment) We could also have some helpers scripts to make management of all those branches easier: - a script to merge / list all topic branches that have not yet been merged into their tor-browser-${firefox_version}-${tbb_version}-1 branch. - a script to push / list all branches that need to be pushed for a firefox or tbb version to a remote git repository. - a script to rebase all patches from a previous firefox version to a new firefox version. What do you think about this idea ? Nicolas

1 7

Missing the meeting today
by Georg Koppen 03 Aug '15

03 Aug '15

Hi folks! It seems I'll miss the meeting today. But I am on #tor-dev later to discuss things (release etc.) if needed. Last week I mainly attended the HTTP workshop and prepared 5.0a4. Today I looked into #16708 and thought a bit about the UX funding proposal + did the remaining things to get 5.0a4 out: I signed the bundles and MAR files and prepared a 5.0a4 blog post draft. Georg

1 0

Re: [tbb-dev] Request for feedback on grant proposal related to usability
by Mike Perry 03 Aug '15

03 Aug '15

I will not be back in time to devote any cycles to this before Monday. isabela: > Hello folks, > I haven't got any votes for a good time to meet yet. I am wondering if > tomorrow (Friday) is too soon. Would be better to have feedback via email? > > My problem is time :) since we will need to submit it soon. Also I would > love to incorporate people's feedback before my next meeting with > SecondMuse (next Tuesday). > > I did went through the doc and added *a lot* of new things there to give > it more shape. Even if you have already taken a look at it, I would > suggest to look again :D because there is much more there from me and > from secondmuse as well. > > Anw, Let me know if I should add more dates for later in the week in > doodle or .. > > Thanks, > Isabela > > > On 07/29/2015 04:47 PM, isabela wrote: > > Hello there, > > > > I am emailing you because I would like to get some feedback on a > > proposal we are trying to put together for SIDA. This proposal is focus > > on usability work, and we are applying with SecondMuse (some of you > > might know them already). > > > > Is a 4 years contract, but not a lot of money. You can find more > > information here: > > > > https://docs.google.com/document/d/1wQ1Dzbe6g8xJYsvO9goOoG90LAfIJYxLrbB2uCo… > > > > What is there is just a draft of an idea on how we could build an user > > centered development process for Tor Browser, which is to bring > > usability checks (user feedback) to early on in the development cycle. > > To achieve that, I thought we could do it with our alpha releases. > > > > I left this to the second year of the contract tho, because I thought we > > could use the first year to give priority to fix a big broken window for > > usability, which is our website. So, I am proposing that during the > > first year, while SecondMuse does their needfinding work, we can redo > > our site. > > > > I met with Elizabeth from SecondMuse yesterday and we will be updating > > this draft with, refining more the idea, we hope to do it by EOD on > > Thursday. So I recommend checking it again :) > > > > Here is a doodle for trying to figure out when is a good time to meet. > > The deadline for this proposal is August 10, this is why I am trying to > > schedule this so soon: > > http://doodle.com/h87zeh3bzcye665c > > > > For this meeting I would very much appreciate if we focus on 'what' more > > than on 'how'. The goal here is to have an agreement on what we will be > > doing for this proposal, since our deadline is very soon. > > > > Let me know if you have questions etc! > > > > Thank you, > > Isabela > > > > -- > PM at TorProject.org > gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B > @isa > -- Mike Perry

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev August 2015