Hi,

(woo, your mail user agent messed up! :( )
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?)

> 
> 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.

> 
> 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,
    Levente Kurusa