Hi,
Erinn Clark:
We need to make a few decisions and commit to a few actions now:
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
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.
- 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?
- 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?
- Tor bundles/installation
Agreed.
- TorBrowserButton
Agreed.
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).
- 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?
We should triage bugs while we are at it to give us a clean, "new" start IMO. Other than that I don't have preferences.
Georg