launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Thu, Oct 6, 2011 at 8:08 AM, Marc Tardif <marc.tardif@xxxxxxxxxxxxx> 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