[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.
- Pick a time and method to begin collapsing things, which will inevitably (and IMO necessarily) involve huge amounts of triaging.
Yay.
--Roger
Roger Dingledine:
Why not Torbutton while we're at it? I guess more broadly, the Torbutton component should be triaged and then lit on fire.
Yes.
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
Regarding "gitian": I think given that other projects are going to use/using it as well (TIMB has an open bug about it; pluggable transports has the famous #9444 and other, follow-up bugs), we should get the bugs tagged with "gitian" out of the Tor bundles/installation (and thus, tbb-bugs) component into an own one (maybe "Gitian"?).
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.
Interesting. I wonder whether the 'Tor' component is comparable to the TBB beast, though, given that the latter seems to be much less homogeneous (it feels sometimes as if it consists only of loosely related components: there are different programming languages involved; there parts that are pretty low-level (e.g. networking related code) and parts that deal with UX...) and might therefore attract different developer types which probably like to keep track of different areas. But maybe that is indeed a non-issue in the long run, dunno.
Georg
-
Georg Koppen -
Roger Dingledine