tbb-dev

tbb-dev@lists.torproject.org

447 discussions

structure TBB more like Firefox?
by Mark Smith 26 Mar '14

26 Mar '14

Mike made a comment here: https://trac.torproject.org/projects/tor/ticket/6457#comment:9 that caused Kathy and me to do some more thinking about the TBB package structure and how we can simplify the patches required for #4234 (Use Firefox updater). The purpose of this message is to get input from everyone. The question: Should we change TBB so it it structured on disk just like Firefox? In other words, can we pull the Firefox ("Browser") directory up to the top of our package? This would provide several advantages: + The patches for #4234 (Use Firefox updater) would be much smaller, which means maintenance would be easier, Mozilla would be more likely to accept the small patches we would be left with, and so on. This would be a *huge* win and it is the main reason we are asking this question. + Bugs such as #6457 (Mac dock icon problems) would disappear. + The TBB package would look less like a bundle and more like a browser that is based on Firefox. There are also some challenges that stopped us from doing this last fall. The RelativeLink wrappers perform some useful functions and it may be difficult to eliminate them entirely. Our current thinking is that we could adopt a slightly different approach for each operating system: - On Mac OS, Kathy and I think we can keep the wrapper script but eliminate the nested .app structure. This should solve the dock icon problems. The main reason we need the wrapper is to ensure that -no-remote is passed to firefox (we do not want someone to try to open TBB and have a new Firefox window open up instead, just because they happen to have Firefox running). Even if we don't make changes for Linux and Windows, it probably makes sense to do so for Mac OS since the package innards are mostly hidden from users. - On Linux, we can keep the wrapper script but move it down into the Firefox ("Browser") directory. To keep end-users from being overwhelmed by all of the files that are in the firefox directory directory, we could provide a symlink at the top and use a structure that looks like this: tor_browser_en_US/ start-tor-browser@ (symlink to Browser/start-tor-browser) Browser/ (Firefox directory) Browser/start-tor-browser (wrapper script) Browser/Tor/ (new parent for Data, Docs, Tor dirs.) Browser/firefox (executable) ... Note that the Firefox updater would not be able to touch anything above the Browser directory, so we can't put anything above that point that we will EVER need to update. But we can probably get away with using one symlink. - On Windows, like Linux, we have the problem of not wanting to overwhelm end-users by showing them a folder with a bunch of files in it and hoping they will locate and open the one named firefox.exe (a challenging task, given that they just installed a package named "Tor Browser"). But we could use a structure similar to what I proposed above for Linux; our Windows installer could create a shortcut that includes -no-remote, e.g., Tor Browser/ Start Tor Browser.lnk (installer-generated shortcut) Browser/ (Firefox directory) Browser/Tor/ (new parent for Data, Docs, Tor dirs.) Browser/firefox.exe ... If, someday, we provide a .zip package on Windows, users of it will need to create their own shortcut or they will need to find and open firefox.exe (but that means they may not neglect to include the -no-remote flag). A side note is that we do not need -no-remote if we are willing to change the Tor Browser to look like a different application (compare to Firefox), i.e., register a different window class on Windows, use a different creator code on Mac OS, etc. But there may be reasons we do not want to be different from Firefox in that way. Opinions on all of the above? Pitfalls? This change will be disruptive to developers, support people, and end-users but the long term benefits might make it worth doing. -- Mark Smith Pearl Crescent http://pearlcrescent.com/

2 2

Tor Browser Weekly IRC meetings moved to 18:00 UTC Fridays
by Mike Perry 20 Mar '14

20 Mar '14

Due to the US Daylight Savings Time changes generating new conflicts for a few people, the Tor Browser team's weekly IRC meeting will now be on Fridays at 18:00 UTC in #tor-dev on irc.oftc.net, starting this Friday, March 21st. We will be snuggling up next to the Huggable^W Pluggable Transports team meeting, which is just before us at 17:00 UTC on alternating Fridays. Their next meeting is March 28th. The hope is that this will help us to work closer with them to polish up the new unified PT-enabled Tor Browser, add new transport types, and otherwise generate PLUR (yeah, I said it). For details on our meeting format, see the original post: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html P.S. We may have to revisit this time again when the EU switches to "Summer Time" on March 30th. Running an hour later in the EU may start to run into people's Friday evening plans, but we'll cross that bridge once it starts burning. -- Mike Perry

1 0

Re: [tbb-dev] Collapsing TBB components on Trac
by Roger Dingledine 17 Mar '14

17 Mar '14

[Sorry for breaking threading; just joined the list and couldn't find an In-reply-to header to use to fake it.] I see the thread is mostly quiet, and it would be great for it to go somewhere, so let me jump in with my own colors for the bike shed. Geko said: > Erinn Clark said: > > - Firefox Patch Issues > > agreed. Agreed. > > - Quality Assurance and Testing(?) > > I wonder if that one really fits here (in the long run!?) as it is > probably meant as a component which covers the QA and testing of all the > (sub) projects we (The Tor Project) have. At least that is my impression > when I look at > https://people.torproject.org/~boklm/automation/tor-automation-review.html > Sure, the TBB is probably the most important one but there are other > projects outlined that are, if at all, only loosely related to it. I think this one should probably stay separate, and hopefully in the future it will grow to be larger and more diverse. > > - TIMB > > Hmm... Not sure what currently is or will be tracked with this component > but that's a different bundle which does not have Firefox patch issues > and does not have Torbutton. So, I am wondering if there is so much > overlapping here. Maybe we can start without it and see how it goes? And this one should stay separate too, since it is specifically not Tor Browser Bundle. > > - Tor Launcher > > Mmmm... I think I'd want to start with it included: TBB is currently the > only one using Tor Launcher. We might want to evaluate this decision > later if we have other bundles using it. Maybe there are not so many > additional things they need to merit an own Tor Launcher component as we > currently have and we could keep it in the tbb-bugs component? Tough one. You will be unhappy either way here. On the theory that Tor Launcher is used by an increasing number of projects that aren't TBB (Tails, TIMB, maybe Torbirdy), I'd be inclined to keep it separate. > > - Tor bundles/installation > > Agreed. This is the most important one to do something about. > > - TorBrowserButton > > Agreed. Yep. Why not Torbutton while we're at it? I guess more broadly, the Torbutton component should be triaged and then lit on fire. > While it is good to fold them into one component to send notifications > to a list, I don't want to miss the ability to search for specific > "subcomponents". Not sure whether there is a good way to do that with > Trac. We (at least I) currently use keywords e.g. for it (see the > "gitian" keyword as example) which kind of works. I can live with that > but am not sure if it is still usable when we only have one big > component (and a lot of keywords). We faced exactly this situation with the 'Tor' component -- we've adopted the unofficial policy of adding keywords tor-client, tor-relay, tor-hs, tor-auth, etc to help people who liked the old "many components" model. But we're slowly finding that we don't need to do that anymore. > > 2. Pick a time and method to begin collapsing things, which will inevitably > > (and IMO necessarily) involve huge amounts of triaging. Yay. --Roger

2 1

PoC of using Mallard for the Tor Browser User Manual
by Lunar 12 Mar '14

12 Mar '14

Hi! On #11124 [1], you will find a proof-of-concept of using Mallard [2] to create the future Tor Browser User Manual. I really like it. It would be great to have an opinion of the TBB team. [1]: https://bugs.torproject.org/11124 [2]: http://projectmallard.org/ -- Lunar <lunar(a)torproject.org>

3 4

How much the Tor Browser is still a Bundle?
by Lunar 12 Mar '14

12 Mar '14

Hi! We usually call Tor's flagship product the “Tor Browser Bundle”. But since Tor Browser 3 and our departure from Vidalia, I'm having a harder time going on calling it a “bundle”. This is really obvious with the Mac OS X version, where users now interact with only a single icon, called “Tor Browser”. One concrete example is the logo and the wording that is visible in the configuration wizard. The logo says “Tor Browser Bundle” and the text right next to it says “Before the Tor Browser Bundle tries…”. Couldn't we just drop the “Bundle” here? For another small unconsistency, the wizard window title is “Tor Network Settings”. (Also, “bundle” is super painful to translate properly in French… but that's a side effect.) -- Lunar <lunar(a)torproject.org>

5 13

Collapsing TBB components on Trac
by Erinn Clark 03 Mar '14

03 Mar '14

Hello everyone! During the dev meeting we had many interesting discussions and agreements about how to proceed as the ultimate TBB dev team. One of them involved collapsing as many components as possible into a single Tor Browser Bundle component on Trac. To this end, we have a new mailing list called tbb-bugs[1] and I've created a Trac user called tbb-team which has tbb-bugs(a)lists.torproject.org as its email address. The idea is to have the huge component have its owner as tbb-team, so that we are able to see all of the bugs assigned to it via the mailing list and then assign the bugs to individuals as needed. We will revisit this topic at the next dev meeting in June to see if it's working out and, if not, figure out a different solution. We need to make a few decisions and commit to a few actions now: 1. Which components do we collapse into the huge TBB component? Here's a list of all of the current Trac components that are candidates: - Firefox Patch Issues - Quality Assurance and Testing(?) - TIMB - Tor Launcher - Tor bundles/installation - TorBrowserButton When we discussed this at the dev meeting it seemed unclear whether Tor Launcher and TIMB would fit into such a component. I'm not sure why they wouldn't -- please share your thoughts. 2. Pick a time and method to begin collapsing things, which will inevitably (and IMO necessarily) involve huge amounts of triaging. We could do this all-at-once with a batch modification to each agreed upon component and then try to deal with the resulting mess later, or we could go component-by-component and try to triage each one of them. It might be easier to do this in smaller teams, 1-3 people, for specific smallish amounts (1-2h) of dedicated time a few times a week. Or we could schedule some insane 8h block where it's all hands on deck. Does anyone have a strong opinion about the best way to organize this? If not, what are your preferences? Thanks, Erinn [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-bugs

3 2

Tor Browser Weekly IRC meetings at 19:00 UTC Wednesdays
by Mike Perry 26 Feb '14

26 Feb '14

At the dev meting, we agreed to hold weekly TBB meetings in #tor-dev on IRC (irc.oftc.net), ideally either before or after the tor-core meetings. It looks like we're going to shoot for Wednesdays at 11:00am PST/19:00 UTC. If we can agree on this time, Nick has said that the tor-core meetings may be able to follow ours, pending approval from the rest of the Tor folks. For the meetings themselves, I think we should try the following format, inspired by Scrum, but less rigid. Everyone makes 0 or more statements on the following three topics, with time for responses from others: 1. What have you been working on last week that other TBB people should be aware of? 2. Will you be working on anything TBB related next week that should/could involve other people? 3. Do you need anything else from anyone else to help you make progress or to get something reviewed+merged? If so, what do you need? These meetings won't be used for progress metrics/evaluation, so don't feel the need to inflate things, explain already-solved snags in detail, discuss your various non-TBB/life distractions, or anything like that. The purpose here is strictly TBB coordination. In particular, if you've been working on stuff that either isn't TBB-related or is too premature to be worth discussing in detail yet, you can skip items 1 and 2 entirely, or make them extremely brief (ie "Worked on the updater"). Similarly, if you're blocked on stuff that doesn't require other people's help/input to solve, you can skip item 3. Don't feel obligated to tell us about issues that involving others won't really help. However, when discussion is necessary, we can and should deviate from the #1/#2/#3 pattern to discuss people's work/questions in some detail without plowing straight through to the next person immediately. After everyone has their turn to say what's they've been doing/what's needed, we can do a little bit of freeform discussion on whatever other issues seem pressing and who should be doing what next, discuss any future releases/deadlines, and discuss recent support issues if any support people are present. We will hard-stop at 20:00 UTC for the tor-core dev meeting to start (but hopefully will finish much earlier than that). If we end up consistently finishing early, we can make it later so as to run more fluidly into the tor-core meeting, for people who want to attend both. -- Mike Perry

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev