> > There hasn't been much of a response to this yet, so I'm assuming > > that > > everyone is OK with the idea of (1) and keeping the blocker > > tracking > > 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 > autoqa one? > > > > > On a related note, the proposal to consolidate autoqa-devel@ and > > other > > QA development discussion on to a single list went over well and > > we've > > started migrating over to the new qa-devel@ list [1] > > > > [1] https://admin.fedoraproject.org/mailman/listinfo/qa-devel > > > > If autoqa is going to be using that mailing list as well then it > makes > 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. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
