[Ksummit-discuss] [TECH TOPIC] QR encoded oops for the kernel
Teodora Baluta
teobaluta at gmail.com
Tue May 13 18:14:21 UTC 2014
On May 13, 2014, at 20:43, Levente Kurusa <levex at 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.
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.
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.
Thanks,
Teodora
More information about the Ksummit-discuss
mailing list