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 …
[View More]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/
[View Less]
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-…
[View More]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
[View Less]
[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 …
[View More]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
[View Less]
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>
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 …
[View More]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>
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
