On Fri, 01 Mar 2013 07:51:00 +0000 "Jóhann B. Guðmundsson" <johannbg@xxxxxxxxx> wrote: > On 02/28/2013 11:51 PM, Tim Flink wrote: > > On Tue, 26 Feb 2013 08:37:01 -0700 > > Tim Flink <tflink@xxxxxxxxxx> wrote: > > > >> There has already been a thread here on this topic [1] but after it > >> came up in the Fedora QA meeting yesterday, we decided to make an > >> actual proposal. > >> > >> [1]http://lists.fedoraproject.org/pipermail/test/2013-February/113898.html > >> > >> The concern raised is that notifications for development related > >> tickets for the blocker tracking app are out of place on the Test > >> list. > >> > >> To solve this, we have a couple of options: > >> > >> 1. Start using the defaultcc plugin for trac such that emails for > >> the blocker tracking app are directed to a new qa-devel@ list > >> > >> 2. Move all development related tickets out of the Fedora QA trac > >> into a new trac instance for the blocker tracking app which uses > >> qa-devel@ for notifications. > >> > >> 3. Move all development related tickets to a different existing > >> trac (probably autoqa) > >> > >> Personally, I don't have any really strong feelings about (1) or > >> (2). (1) is probably a little less work in the short term but (2) > >> isn't a bad idea. I'm somewhat strongly -1 on (3), though - If I > >> need to go through and do the work of moving tickets and changing > >> settings, I don't really want to be hacking up another project's > >> trac instance. > >> > >> I've already started a thread on autoqa-devel@ asking about > >> combining that list with a new qa-devel@ [2]. The initial response > >> has been positive - I don't expect that will be a problem. > >> > >> [2]https://lists.fedorahosted.org/pipermail/autoqa-devel/2013-February/003519.html > >> > >> Anyhow, thoughts on the possible solutions or how much work the > >> problem is worth? > > 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? I remember that being discussed but IIRC, we decided to send a proposal on how to move forward to the list for discussion. > > > > 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. Kamil pretty much covered everything that I would have said in his email. Trac doesn't do well with multiple projects and while it happens to not be terrible for BBA and fedora-qa, it doesn't work well in general. I understand the desire to reduce the number of trac instances and honestly, I'd rather not have another instance to admin. However, the costs of having to deal with a sub-optimal tracker configuration just for the sake of having a single instance are just too high to make sense. Tim
Attachment:
signature.asc
Description: PGP signature
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
