Re: [Ksummit-discuss] [TECH TOPIC] QR encoded oops for the kernel

["Teodora Băluţă" <teobaluta@gmail.com>]

Hi,

> (woo, your mail user agent messed up! :( )

Yes, I didn't send it from my laptop, but from mobile. I'm sorry, I
noticed that too late. :(

> On Tue, May 13, 2014 at 09:14:21PM +0300, Teodora Baluta wrote:
>>
>> On May 13, 2014, at 20:43, Levente Kurusa <levex@linux.com> wrote:
>>
>> Hi,
>>
>> > On Tue, May 13, 2014 at 12:07:43PM -0400, Theodore Ts'o wrote:
>> > I'll note this discussion has started mutating to a more general "how
>> > do we get more useful bug reports in front of developers", which I
>> > think is a good thing.
>> >
>> > However, I'm still not sure how useful it would be to have a tech
>> > topic (or a core topic) dedicated to the matter, because we've had
>> > discussions about and at the end of the day, what's probably really
>> > necessary is to have someone, or a small team, dedicated all or most
>> > of their time to:
>> >
>> > a) improving kerneloops.org
>> > b) finding interesting patterns in the bulk reported data, and then
>> > forwarding that on to developers
>> > c) finding ways of automating (b)
>>
>> * One possible way of improving kerneloops is that once an oops happens
>>  more than X times then it would be automatically sent to the
>>  maintainer.
>>
>> * Adding some more stats specifically for the RCs, so we can get more
>>  information during the RC phase of a release.
>>  We have essentially the same for Stable and Longterm kernels.
>>
>> (By the way, am I the only receiving frequent 503 Service Unavailable
>> errors from the oops.kernel.org site?)
>>
>> I also have the same error code. So another possible subject is adding the infrastructure/web service for sending oops messages. As I understood for Konstantin, the current API is a bit tricky to use so maybe adding a simple REST API could simplify the pushing process.
>
> I have no idea how the oops.kernel.org API works, sadly. Can you please give
> some insight (for instance, where the oops is parsed. in ABRT and such
> or in the server?)

I don't know how oops.kernel.org API works either, but I talked to
Konstantin about bugzilla and the problem is authentication (the app
could use an account 'qruploader' or each user to have each account).
Either way, it is not a very good option for easily sending an oops.
The implementation is a xml-rpc interface (for more check out [0]) but
you could add a layer like REST if you want to use the browser (an
interesting article here [1]).

[0] http://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/WebService/Server/XMLRPC.html
[1] http://www.etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/

>
>>
>> Maybe one of the problems is not having where to send these bugs easily with an automated process.
>>
>> I am doing an app now so how can I make it worth the time? Should I just forget about bugzilla and just implement a server that collects these reports?
>>
>> If it helps I can just post the link to the repository to the Android app to get an idea how it looks (still in development).
>> >
>> > QR encoded oops might be a means towards that end, but there might be
>> > other things that could be done as well.
>> >
>> > If someone were to *do* all of this work, then reporting on it and
>> > then asking for suggestions about how this service could be improved,
>> > might make a great tech topic.
>> >
>> > But in the absence of that, can folks suggest ways that this doesn't
>> > turn into a "I know, let's put a bell on the cat!" sort of discussion
>> > that doesn't lead to anything useful?
>>
>>
>> Here are a few topics I think are worth discussing at the summit with
>> regards to this topic:
>>
>> * How to disseminate bug reports?
>>   Have comaintainers looking at bugzilla and oops.kernel.org?
>>  For some time now, I have been trying to do some cleanup, i.e.
>>  fix some bugs there, but since I lack the capabilities to close bugs
>>  it still remains to others. I would, though, be very pleased to
>>  clean up bugzilla, if I got the capabilities.
>>
>> * QR code in general.
>>   Is it actually worth it? I mean as it currently stands the QR code
>>  takes quite a bit of the screen and takes place over some (possibly
>>  valuable) information. This is because it is currently in the
>>  topleft corner. There was a suggestion to move it to the center, but
>>  I think that would as well take some information away from someone
>>  who wants to find out the information themselves.
>>
>>   If we accept the QR encoding stuff to the kernel, then that will
>>  most likely mean that kerneloops will receive more (probably
>>  valuable) information. I think that this is a good thing, since as
>>  Greg mentioned we will better now which subsystems struggle. Maybe
>>  adding a bugzilla entry as well seems reasonable and maybe if we do
>>  clean up bugzilla, maintainers will eventually look at it and the
>>  bugzilla thing will become viable.
>>
>>   Automatically adding a bugzilla might make sense as well once a
>>  certain oops hits the 'X-times-happenned' level. That way
>>  maintainers wouldn't be overflown with new bugs by mail.
>>
>> * Should maintainers be sent digests of the oopses from
>>  oops.kernel.org and the bugs from bugzilla?
>>   Okay, I know that most maintainers get mails from the bugzilla each
>>  time a new bug is filed, but I guess a digest would be better. It
>>  wouldn't overflow a maintainer's mailbox nor it would be
>>  automatically added to the maintainer's spam folder.
>>  A feature like this already exists in bugzilla, in the 'Reports'
>>  menu, but it does not send any mails, so I guess that could be
>>  automatized.
>>
>> Another suggestion is to add the possibility of analyzing bugs on the server side: like it was said previously on this thread, keeping an eye on the feeds that repeat more than X times. Or see which subsystem have most issues.
>
> I am not sure what you mean by 'analyze'. Can you please elaborate?
> The current oops.kernel.org does display some information on the top
> guilty drivers and modules. It's right on the front page.
>

I was referring to the ones on oops.kernel.org but I don't know it the
site oops.kernel.org can be used in any way... I have the same
question, what is the API for it?

>>
>> After all, if the commitee decides that this topic is viable, I would
>> be happy to participate.
>>
>> I would be happy to continue working on this and leading the discussion if there is enough interest in discussing use of QR code in this process as we *do* have the prototype and the people (Levente and me) if there is support (infrastructure, feedback, etc. ) in adding this upstream.
>
> I guess the discussion at the KS won't be mostly about QR codes, but
> rather how could we get more information on the OOPSes and how to
> disseminate them. Obviously, QR codes can play a huge part in this if
> we manage to make them as least demanding as possible. Again, I'd like
> to express my opinion on forcing the user to download an app just to
> parse an oops is less than ideal. I still strongly support going for
> a URL and a baseXX encoded approach. Obviously, there are problems
> with this way as well, but this is the way where we lose the least
> amount of users IMHO. :-)
>
> Regarding your comment that base64 adds 33% overhead. If we manage to
> shrink the size of the OOPS, i.e. remove registers, and some other
> stuff, then that may compensate for the overhead b64 adds. There
> is a subthread that discusses this.

Thanks,
Teodora