[tbb-dev] Collapsing TBB components on Trac

[Georg Koppen]

Hi,

Erinn Clark:
> 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

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20140303/75870aa7/attachment.sig>