ubuntu-phone team mailing list archive

[Sergio Schvezov <sergio.schvezov@xxxxxxxxxxxxx>]

On Saturday, December 20, 2014, Victor Thompson <victor.thompson@xxxxxxxxx>
wrote:
> Robert, we are on the same page here (more or less) :)
> On Fri, Dec 19, 2014 at 8:59 PM, Robert Schroll <rschroll@xxxxxxxxx>
wrote:
>>>
>>> LP is not a full solution since it leaves out potentially many
developers and their apps--so why even consider it?
>>
>> Because it exists.
>>
>> Look, it'd be great to have this work with all bug trackers ever.  It'd
be great to design a new bug tracker that's fully integrated with the click
store and myapps.ubuntu.com.  But that's a whole lot of work for an already
over-extended project.
>>
>> I feel like this could be implemented in a person-week.  Less, perhaps,
if that person were already a scopes and Launchpad expert.  Once that's
working and insanely popular, we could add other backends.
>
> I still have to reiterate that a full solution for all developers is
necessary. I'd like to revise my previous statement that we should have a
checkbox for "buggy" apps. I think we may want two: 1) the app is "Broken",
2) the app "Very poor in performance.".

With my user hat on, a buggy application is just a bad application (read on
for comments on an in development scenario).

> I understand your frustration, Robert. The Music app has, perhaps, seen
the most breakages of any app. No, actually I can guarantee that the Music
app has seen the most breakages. Matter of fact, the Music app has probably
seen more breakages than all the core apps combined. We have had to deal
with changes in the SDK (like you), but also changes in media-hub (which
provides the sound and video backend to the system--changes have been fast
moving, awesome, and will continue as the platform expands to service more
than the phone), mediascanner (which provides metadata for the Music app
and the "My Music" and "Music" scopes, it may be a little bit more
solidified now, however), and various other changes in packages concerning
media playback (oxide, gstreamer, codecs, etc).  Also, I maintain a few web
apps that have (at various stages in their lifespan) been very
unresponsive. Shamefully unresponsive. I feel I am the foremost authority
on broken and poorly performing apps. *sigh*

Maybe just channel information in the review is enough. I bet most of the
breakages come from people running devel-proposed. I'd assume anyone
running that has sufficient knowledge to find the bug tracker and if the
ratings are separated correctly, it will provide enough assurance to just
dismiss the review.

> This is why I think we need a full stop solution that doesn't include a
bug reporter. The solution needs to be integrated into the store UI itself
and needs to be part of the data it maintains. Anything less is a waste.
> That being said, I do want to express my optimism that breakages will
hopefully be nonexistent once the first device is released. I agree with
you 100%, it has been hard triaging the stuff left in reviews. And you also
already understand that the users are a bit frustrated when they file this
information. They aren't even paying customers!  It'll be even more
important to have stability once the device is released. But nonetheless,
introducing a bug tracker will not help their piece of mind and it will
only serve to add further confusion.
>
>>>
>>> I don't want users to be forced to file LP bugs in order to get bugs
fixed in any of my future projects.
>>
>> The user shouldn't know or care that the bug is being filed on LP, or
anywhere else.  They get a text box, a submit button, and, a few
days/weeks/months later, an email saying the bug has been fixed.

As a user, if it's broken, I'll review and remove. Your best bet here is
silent or recoverable errors reported to errors.ubuntu.com with enorugh
info for you to fix in the background.

>>
>> Right now, they would need to interact with LP to follow up on the bug.
But if we can get LP to steal Github's respond-by-email mechanic, even that
wouldn't be necessary.
>>
>> Robert
>>
>
>