On 15 November 2011 19:52, Aaron Bentley <aa...@canonical.com> wrote: > Better support for QA. Marking bugs qa-ok or qa-bad doesn't reflect > our model, because qa-ok means "the associated revision is > deployable", whether or not it fixes the bug. Let's do it directly, > and provide a way to mark revisions deployable/undeployable. > > ... > > Event-based jobs. Currently, we poll to see what jobs to run. > Instead, we should use an event system, such as RabbitMQ, to run the > jobs as soon as they're requested.
+1 on both of these. We discussed tracking QA states in the bug tracker some time back - pre-reshuffle anyway. I don't remember there being any technical reasons for not doing it, but ISTR (fuzzily) there were some questions about how to incorporate it into our bug workflow without making the bug UI even more confusing. A thought that comes to mind is that it would be worth setting aside some time at the Thunderepic in January to brainstorm some of these ideas. With all that assembled grey matter we should be able to come up with some half-decent solutions to these problems that we could then use as a concrete foundation for later work. -- Graham Binns | PGP Key: EC66FA7D http://launchpad.net/~gmb _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
