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

[Levente Kurusa <levex@linux.com>]

[-- Attachment #1: Type: text/plain, Size: 5524 bytes --]

Hi,

On Sun, May 11, 2014 at 06:37:47PM +0200, Laurent Pinchart wrote:
> On Sunday 11 May 2014 18:29:18 Levente Kurusa wrote:
> > On Sun, May 11, 2014 at 08:57:01AM -0700, Sarah A Sharp wrote:
> > > On Sat, May 10, 2014 at 9:14 PM, Jason Cooper wrote:
> > > > All,
> > > > 
> > > > I recently came across a patch series attempting to implement encoding
> > > > kernel oops into a QR code [1].  The QR code is then dumped to the
> > > > 
> > > > framebuffer.  The QR code is a URL of the form:
> > > >   https://oops.kernel.org/?qr=<base64 compressed oops>
> > > > 
> > > > This proposal is interesting because it fundamentally changes the way
> > > > users report bugs to the kernel community.  First and foremost, it makes
> > > > it much easier.
> > > > 
> > > >   1) oops occurs
> > > >   2) user pulls out phone, scans QR code
> > > >       - at this point, the oops is recorded on the server.  Nothing more
> > > >         is required of the user.
> > 
> > To be precise, most scanners don't automatically open the links
> > found in QR codes and hence a tap/click from the user is required. :-)
> > 
> > > >   optionally:
> > > >   
> > > >   3) user fills out a minimal web form
> > > >       - Name
> > > >       - email address (do you want to receive emails re this oops?)
> > > >       - what were you doing when it occurred?
> > > >       - is it repeatable?
> > > 
> > > By "web form", do you mean a new form or something that's part of
> > > kerneloops.org?
> > > 
> > > It would be great if we could allow users to open a new
> > > bugzilla.kernel.org entry for the oops.  I believe Teodora is working
> > > on an Android app that could do this.  Hopefully it could store
> > > information about the person's system, and pre-propagate the bugzilla
> > > entry with this information.
> > 
> > Yes, opening a bugzilla entry might be a good idea if the user fills
> > out the form. To be honest, I think for that to work we would need to
> > clean up bugzilla a bit. I try to do some work there every now and
> > then, but nobody is closing the bugs I have fixed...
> > 
> > Not sure about how would we create the bugzilla entry? I mean, which
> > section, urgency, etc. how would we decide on those solely based on
> > the OOPS? Or should we ask the user to fill it out?
> 
> Filling a complex form on a handheld device can be pretty tedious. A two steps 
> procedure that would allow entering long text on a real computer could be an 
> interesting option.
> 

Makes sense.

What about only asking for an email address and then sending them
an automated message with a link where they can continue to add more
information to the report? (i.e. fill out the bugzilla)

I guess we should also be careful with the bugzilla. We really don't
want propertiary driver crashes added to the bugzilla automatically.
Nor do we want the same oops added twice, right? How would we
differentiate between the two - essentially the same - oopses?
Obviously, if we find two 'same' oopses then we can add the new
info to the old bug.

Maybe add filter based on 'P' taint to solve the propertiary issue.

Oh and of course the email address thing would be optional.

> > > > I recall discussing this with some RedHat devs at the 2012 KS, so I know
> > > > there is some interest in this capability.
> > > > 
> > > > I'd be interested in having this as a tech topic for several reasons.
> > > > First, to raise awareness of the project among the kernel community
> > > > (where did all these oops reports start coming from?).  Second, to
> > > > solicit opinions on how to feed those oops reports into the community.
> > > > And last, to sit down with the maintainer of oops.kernel.org and scope
> > > > out what work needs to be done to support this on the server side.
> > > > 
> > > > Of course, all of this assumes the patches get accepted.  There's been
> > > > no rejections so far, though. :)
> > > > 
> > > > If accepted, I would expect the authors to be the ones leading the
> > > > discussion (Levente, Teodora).
> > > 
> > > I would recommend that Teodora lead the discussion, since this is her
> > > project.  Levente has been provided helpful commentary and additional
> > > patches, and should definitely participate in the discussion as well.
> > 
> > I was just about to say that the order might not be the most correct. :-)
> > 
> > However, I am more than happy to help Teodora lead the discussion if
> > she decides so.
> > 
> > > > Nominations:
> > > > 
> > > > Levente Kurusa <levex@linux.com>
> > > > Teodora Băluţă <teobaluta@gmail.com>
> > > > 
> > > > Relevant folks:
> > > > 
> > > > Konstantin Ryabitsev <mricon@kernel.org>
> > > > Jason Cooper <jason@lakedaemon.net>             (auto-nominated)
> > > 
> > > Another relevant person to include would be PJ Waskiewicz.  Teo worked
> > > on the QR code generator during her internship with the FOSS Outreach
> > > Program for Women (OPW) and PJ was her mentor for the project.
> > > 
> > > You mentioned the kerneloops.org maintainer, but didn't list him here?
> > > 
> > >  Anton Arapov looks to be the maintainer, since he's the only
> > > 
> > > contributor to the kerneloops.org github repo.
> > > 
> > > The idea for the oops QR code generator came from Peter Anvin and Dirk
> > > Hohndel, so they may want to participate in the discussion as well.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Thanks,
    Levente Kurusa

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]