[tbb-dev] Collapsing TBB components on Trac

Roger Dingledine arma at mit.edu
Sat Mar 15 19:38:43 UTC 2014

[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.


> >    - 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.


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.



More information about the tbb-dev mailing list