On Mon, Aug 8, 2011 at 8:05 PM, Rick Spencer <[email protected]> wrote: > On Mon, 2011-08-08 at 19:44 +1200, Robert Collins wrote: >> On Mon, Aug 8, 2011 at 6:25 PM, Christopher James Halse Rogers >> <[email protected]> wrote: >> The LP team doesn't *currently* have working on this in our short term >> plans; if the stakeholders wanted to negotiate queue jumping, we could >> put a squad on it at the end of the next(ish) project, or some folk >> may do something in scratch time (like my experiment with cassandra >> has been). >> > > I'm wondering why the launchpad team would work on this. It seems that > the desire is to collect the crash data outside of lp bug reports.
LP isn't defined by the features we have - they shift over time :) > Am I missing something? Theres a few potential reasons. One is very simple: we need it ourselves; we logged about 14 thousand crash reports yesterday from Launchpad itself into our first-gen crash database (e.g. https://lp-oops.canonical.com/oops.py/?oopsid=1971CBA7). We have some automated analysis of this today but its a kludgy system: high latency, no adhoc analysis, single tenant (and as Launchpad moves to a more SOA model multitenancy or something like it will matter more), no efficient searching. This is much the same reason that Mozilla has built a crash database, for instance. Secondly, one of the things Launchpad exists to do is to provide a solid platform for folk writing software - I see a generic, extensible crash database as something many projects would benefit from. That would be a separate project of course, but a relatively small step up from a just-for-our-own-crashes service. Right now I know of the following Canonical sponsored-or-related projects which could use such a service: t Ubuntu one (server), landscape (server) and Canonical ISD (SSO etc). Not to mention Ubuntu, of course. I can well imagine projects like drizzle, openerp or openstack, wanting to gather anonymised crash data even when folk are running snapshots, or unpackaged builds. (Packages on Ubuntu would naturally get reports gathered without the upstream being a direct user, but there are lots of unpackaged use cases for regular software, let alone web server stacks (consider all the virtualenv based django deployments out there...). Thirdly, as a team Launchpad /started/ as a project to satisfy the server-side infrastructure needs of Ubuntu; supporting Ubuntu's collaboration with Debian, with Upstream, supporting Translations of Ubuntu, and over time this has grown - soyuz was written for Ubuntu, blueprints for UDS. Of course, Launchpad has users beyond Ubuntu, in our capacity as a hosting forge for upstreams, and as a hosting site for derivatives like the OEM flavours and Linaro, but providing services that are primarily, or even exclusively, needed by Ubuntu is well within our mandate. The crash database concept is clearly not one of these exclusively-for-Ubuntu cases (even without aiming at multitenancy, LP needs one itself). We had painted ourselves into a process corner a while back which lead to us having to push back on the amount of things we undertake... but the team have been working fearlessly to fix that, and I think we're over the hump now - on the way back to short, high quality and fast iterations. Fourth, the total workflow desired is to capture crashes and derive bug reports from that: defining Launchpads relationship to crashes by our current implementation would be overly strict IMO: I think LP will *need* to be involved, at minimum, in the crashdb -> bug mapping process / mechanism (e.g. for questions like 'which crash reports are related to this bug' to be answered in the web UI). It doesn't matter whether the crash database is maintained by a different team or not, we'll need integration. Lastly, while the particular form of scalability needed is different to that needed by Launchpad's existing services, writing web services is what the Launchpad team is all about, and we've several services that have similar scaling needs (though different in detail and in likely implementation) - things like the librarian and codehosting. We're already planning on how we will split those out into separate web services which can be scaled separately and reused more effectively. -Rob -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
