On Thu, Oct 6, 2011 at 8:08 AM, Marc Tardif <marc.tar...@canonical.com> wrote: > Hi folks, > > Some of you might've noticed some bugs appear on your radar reported > against the Launchpad Results project [1]. The reason is that the > project is actually part of the Launchpad Suite because it is intended > to become a microservice as described under the Services Analysis wiki > page [2]. The project is aware of the Bug Triage rules in Launchpad > [3] and it would only benefit from following the same rules. So, if you > encounter untriaged bugs for Launchpad Results, please feel comfortable > triaging them the same way you would for Launchpad itself. > > For your reassurance, the point is not to delegate triaging of bugs > reported against the Launchpad Results project to the Launchpad rota. In > fact, this should not happen often in practice. The point is rather > to enable Launchpad to keep driving the bug triage count down even for > other projects under way.
Thanks for announcing this! In some ways this is the natural evolution of the hwdb facility in LP, though its more generic (can handle other sorts of tests too). For clarity - as I understand it launchpad-results is resourced independently of Launchpad, so it may have high bugs that won't count against our 6 month estimate, and maintenance squads won't be dealing with critical bugs in it. (Conversely, launchpad-results will be keeping its set of high bugs under control, and dealing with criticals promptly). The exact project-level details of longer term integration haven't been nutted out with Matt and Francis yet (Matt hadn't been promoted when the launchpad-results project matured enough to ask for inclusion and assessment of how - so Francis channeled the spirit of jml at the time, about 6 weeks back)... the technical stuff has a roadmap (which we should write up). In fact, let me brain-dump my memory of it: launchpad-results currently has a web UI, including greasemonkey hacks in to LP itself, a wadl based json API, and data storage. It consumes the Launchpad json API and could consume a librarian API if we had one. Long term, we think it should be structured like this: - web UI in the Launchpad tree (so no more greasemonkey hacks :), no copying of css needed etc.) - Launchpad should consume the launchpad-results API to deliver the web UI - Launchpad should offer a front-end to the launchpad-results API (so allowing seamless transition into and out of its content) - Launchpad-results should get extended LP API's (possibly internal-xmlrpc ones) to allow more efficient access to Person and Project information, syncing of renames etc. - launchpad-results would keep its API and data storage - providing the contract and implementation -Rob _______________________________________________ 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
