ubuntu-appstore-developers team mailing list archive

[Martin Albisetti <martin.albisetti@xxxxxxxxxxxxx>]

On Thu, Aug 15, 2013 at 7:58 AM, Evan Dandrea
<evan.dandrea@xxxxxxxxxxxxx> wrote:
>> That's a great question. I think you're right, we'd still want some
>> insight into applications that are generally buggy, but I would say we
>> want different views on the data. Currently, as I understand it, we've
>> got errors.u.c integrated with open source applications. In MyApps, it
>> could be either. I'd bet that proprietary application developers would
>> like to keep the specifics of the errors private to themselves, and we
>> would only maybe see a total of failures.
>
> I cannot think of a way of doing this without the data living on
> Canonical servers.

Sorry, I think I'm not being very understandable  :)
I think it's fine for it to live on Canonical servers (required,
even), but I think that's different from Canonical employees being
able to access the data.


> For us to figure out what makes a particular crash an instance of a
> problem (or bug) we need to generate a complete stacktrace. In the
> case of binary programs this involves retracing it, which we cannot do
> client-side (unless we stop stripping binaries). So I think the best
> solution will be that developers provide us with a binary and symbols
> on MyApps. When a crash occurs, the report is submitted to
> daisy.ubuntu.com and it's retraced using the developer-provided
> symbols. The pages for problems (collections of crashes) on
> https://errors.ubuntu.com are then locked down to the Launchpad/SSO
> team responsible for them.
>
> We could extend this to hide data from the leaderboard on the front
> page of https://errors.ubuntu.com that the person viewing the page
> doesn't have the ability to drill down into, but I like the idea of
> keeping developers honest by maintaining a publicly-viewable list of
> the most pressing problems in Ubuntu. Happy to entertain differing
> views though :)

> So what we need to make this happen:
> - A means of getting the symbols for a package and version tuple from
> MyApps (assuming we want the data to live there).
> - An API method for getting the Launchpad/SSO teams (I'm assuming this
> is what you're using for auth?) responsible for a package from MyApps.

Right, that sounds accurate.


>> I think for a seamless experience, we may want to provide all relevant
>> information from the same place. Do you think errors.u.c could grow an
>> API that we could query from MyApps to provide information from there?
>
> I'm happy to add APIs, but it's not clear to me what you're asking for
> here. Could you please elaborate on what you mean by "query from
> MyApps to provide information from there"?

Exactly what you said above. A set of APIs that MyApps could query to
get information for application crashes so we can display it within
MyApps, as opposed to making the developers jump between 2 different
websites to gather information about their app.

This totally sounds like a vUDS session, which I can see you have
already scheduled  :)


-- 
Martin