> There hasn't been much of a response to this yet, so I'm
> everyone is OK with the idea of (1) and keeping the blocker
> app bugs on the fedora-qa trac. If we're going to migrate to a new
> trac instance, I'd rather do it soon (in the next week) since we're
> getting close to the F19 branch date.
Did we not agree moving this into it's separated tracker or use
> On a related note, the proposal to consolidate autoqa-devel@ and
> QA development discussion on to a single list went over well and
> started migrating over to the new qa-devel@ list 
>  https://admin.fedoraproject.org/mailman/listinfo/qa-devel
If autoqa is going to be using that mailing list as well then it
sense to move into their tracker as well.
I see a very large distinction between a shared mailing list for notifications and a
shared trac instance. What you talk about is the (3) proposal and neither me nor tflink
think it's a good idea. AutoQA trac has lots of components and tickets and the Blocker
Bugs App would get lost there, creating confusion. Trac is not really suited for hosting
several projects. In Fedora QA trac is the separation is clearer, because the other
components are not development related. Also it's more logical to look for BBA tickets
there than in another project's trac. As long as BBA stays really small (a single
component in trac), I think it can stay that way.
By the way, I see this topic relevant just for developers of one of Fedora QA apps, it
doesn't really influence the testers community in any way - the email notifications
influence them (and the solution is clear there), not the trac location. So I wouldn't
waste too much time on discussions and explanations here. Let's try the
trac-defaultcc-plugin, if it doesn't work we can try something else.