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

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

[Jason Cooper]

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.

  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?

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

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


thx,

Jason.

[1] https://lkml.org/lkml/2014/3/17/525

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

[Sarah A Sharp]

On Sat, May 10, 2014 at 9:14 PM, Jason Cooper <jason@lakedaemon.net> 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.
>
>   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.

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

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

Sarah Sharp

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

[Levente Kurusa]

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

Hi,

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 <jason@lakedaemon.net> 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?

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

Thanks,
Levente Kurusa

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

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

[Laurent Pinchart]

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.

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

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

[Levente Kurusa]

[-- 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 --]

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

[Teodora Băluţă]

Hi,

On Sun, May 11, 2014 at 8:18 PM, Levente Kurusa <levex@linux.com> wrote:
> 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. :-)

That's correct, you still need a click, so maybe a special Android app
could do the work so you don't need to turn the compressed oops into
base64.

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

I am and I've got the part of scanning and decompressing the QR oops
into text done. The way I see it, you may want to simply read the oops
on the phone or tablet so you should be able to keep a local history
of Oops that you've scanned. You can add your profile information for
bugzilla.kernel.org and then set an option to automatically send Oops
messages you scanned or save them and send them later. I've sent an
email to Konstantin, the maintainer of bugzilla.kernel.org, asking for
more details on the actual sending of the Oops message.

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

I think you could receive an email with a link to a partially
completed bug report (which you sent when scanning the QR code) and
follow that link on you computer to add stuff to your report. That'd
be nice, wouldn't it?

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

Indeed, if you have too much to fill in on your smartphone it could be
inefficient.

>
> 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 think it'd be a great experience if I could hold a presentation! :)
The feedback was really great especially since this is a first for me!

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

Thanks,
Teodora

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

[Laurent Pinchart]

Hi,

On Sunday 11 May 2014 20:52:12 Teodora Băluţă wrote:
> On Sun, May 11, 2014 at 8:18 PM, Levente Kurusa <levex@linux.com> wrote:
> > 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. :-)
> 
> That's correct, you still need a click, so maybe a special Android app
> could do the work so you don't need to turn the compressed oops into
> base64.
> 
> >> > > >   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.
> 
> I am and I've got the part of scanning and decompressing the QR oops
> into text done. The way I see it, you may want to simply read the oops
> on the phone or tablet so you should be able to keep a local history
> of Oops that you've scanned. You can add your profile information for
> bugzilla.kernel.org and then set an option to automatically send Oops
> messages you scanned or save them and send them later. I've sent an
> email to Konstantin, the maintainer of bugzilla.kernel.org, asking for
> more details on the actual sending of the Oops message.
> 
> >> > 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.
> 
> I think you could receive an email with a link to a partially
> completed bug report (which you sent when scanning the QR code) and
> follow that link on you computer to add stuff to your report. That'd
> be nice, wouldn't it?

Yes, that would do it I believe. It would also allow easier spam filtering, as 
oops submissions would need to be followed up by a user action before the 
bugzilla bug gets created.

> > 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)
> 
> Indeed, if you have too much to fill in on your smartphone it could be
> inefficient.
> 
> > 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 think it'd be a great experience if I could hold a presentation! :)
> The feedback was really great especially since this is a first for me!
> 
> >> > 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

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

[Jason Cooper]

On Sun, May 11, 2014 at 08:52:12PM +0300, Teodora Băluţă wrote:
> On Sun, May 11, 2014 at 8:18 PM, Levente Kurusa <levex@linux.com> wrote:
> > 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. :-)
> 
> That's correct, you still need a click, so maybe a special Android app
> could do the work so you don't need to turn the compressed oops into
> base64.

I'd like the URL to be valid (meaning base64 the compressed data) so
that we can get the data to the kernel.org server as easily as possible.
Making the app a requirement for reporting is too onerous for
non-developers.  I see no reason we can't link to (Open in/Install) it
on the webform though.

I see your app as a great tool for people developing the kernel or
curious about what happened, but there will be a significant number of
users who don't develop (possibly anything) who won't go to the effort
to install an app just to help us out.  Knowing how many of those folks
are affected by the bug is, imho, a very important data point when
triaging bugs.

Even though these 'users' don't talk on lkml, they *do* exist.  And they
say mean things like "Linux crashes on my $LAPTOP, it sucks."  I'd rather
not have to get a facebook account to learn that. :)

thx,

Jason.

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

[Levente Kurusa]

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

Hi,

On Mon, May 12, 2014 at 12:15:39PM -0400, Jason Cooper wrote:
> On Sun, May 11, 2014 at 08:52:12PM +0300, Teodora Băluţă wrote:
> > On Sun, May 11, 2014 at 8:18 PM, Levente Kurusa <levex@linux.com> wrote:
> > > 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. :-)
> > 
> > That's correct, you still need a click, so maybe a special Android app
> > could do the work so you don't need to turn the compressed oops into
> > base64.
> 
> I'd like the URL to be valid (meaning base64 the compressed data) so
> that we can get the data to the kernel.org server as easily as possible.
> Making the app a requirement for reporting is too onerous for
> non-developers.  I see no reason we can't link to (Open in/Install) it
> on the webform though.

+1, the app is a good idea but shouldn't at all be mandatory. If we
add that as a requirement people might just get lazy and don't
download the app at which point we lose the report. Of course,
adding the app as a plus is a great idea, since then the geeky people
can take a look at what really happenned if the QR code has messed up
their stack traces or whatever they see on their screen.

> 
> I see your app as a great tool for people developing the kernel or
> curious about what happened, but there will be a significant number of
> users who don't develop (possibly anything) who won't go to the effort
> to install an app just to help us out.  Knowing how many of those folks
> are affected by the bug is, imho, a very important data point when
> triaging bugs.

Yup, I think it's almost the same as with requiring the user to fill
out a long seemingly endless form. Let's be as small as we can, while
having the possibility of adding more and more data.

> 
> Even though these 'users' don't talk on lkml, they *do* exist.  And they
> say mean things like "Linux crashes on my $LAPTOP, it sucks."  I'd rather
> not have to get a facebook account to learn that. :)

If only, I had counted how many bad quality photos of people's screens
did I get so far. :-)

Thanks,
    Levente Kurusa

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

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

[H. Peter Anvin]

On 05/12/2014 09:36 AM, Levente Kurusa wrote:
> 
> If only, I had counted how many bad quality photos of people's
> screens did I get so far. :-)
> 

This is not at all surprising.

Keep in mind that the QR code stuff is only going to be helpful if it
contains more information and/or decodes better than text screen photos.

	-hpa

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

[Steven Rostedt]

On Mon, 12 May 2014 09:53:40 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On 05/12/2014 09:36 AM, Levente Kurusa wrote:
> > 
> > If only, I had counted how many bad quality photos of people's
> > screens did I get so far. :-)
> > 
> 
> This is not at all surprising.
> 
> Keep in mind that the QR code stuff is only going to be helpful if it
> contains more information and/or decodes better than text screen photos.

What would be nice is if it recorded the first part of a bug oops, and
ignored the later part of the dmesg. You know, the important stuff that
scrolls off the console. I hate it when people send me the last oops
message that was caused by three oops messages that happened before it.

Pretty much every screen shot that I received was of an oops that was
caused by a prior oops and was deemed useless.

-- Steve

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

[Johannes Berg]

On Mon, 2014-05-12 at 18:36 +0200, Levente Kurusa wrote:

> > I'd like the URL to be valid (meaning base64 the compressed data) so
> > that we can get the data to the kernel.org server as easily as possible.
> > Making the app a requirement for reporting is too onerous for
> > non-developers.  I see no reason we can't link to (Open in/Install) it
> > on the webform though.
> 
> +1, the app is a good idea but shouldn't at all be mandatory. If we
> add that as a requirement people might just get lazy and don't
> download the app at which point we lose the report. Of course,
> adding the app as a plus is a great idea, since then the geeky people
> can take a look at what really happenned if the QR code has messed up
> their stack traces or whatever they see on their screen.

If you have a well-known URL prefix then as far as I know you can (at
least on Android) still have a URL and invoke an app if it's installed,
via the intents system. You could thus still have a URL that displays
the information, or a local app that does it and can do more.

johannes

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

[Teodora Băluţă]

On Mon, May 12, 2014 at 8:00 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2014-05-12 at 18:36 +0200, Levente Kurusa wrote:
>
>> > I'd like the URL to be valid (meaning base64 the compressed data) so
>> > that we can get the data to the kernel.org server as easily as possible.
>> > Making the app a requirement for reporting is too onerous for
>> > non-developers.  I see no reason we can't link to (Open in/Install) it
>> > on the webform though.
>>
>> +1, the app is a good idea but shouldn't at all be mandatory. If we
>> add that as a requirement people might just get lazy and don't
>> download the app at which point we lose the report. Of course,
>> adding the app as a plus is a great idea, since then the geeky people
>> can take a look at what really happenned if the QR code has messed up
>> their stack traces or whatever they see on their screen.
>
> If you have a well-known URL prefix then as far as I know you can (at
> least on Android) still have a URL and invoke an app if it's installed,
> via the intents system. You could thus still have a URL that displays
> the information, or a local app that does it and can do more.

That's right.You can select to see the text of the Oops or just send
it to a predefined server. :)

>
> johannes
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Teodora Băluţă]

+ everyone else

On Mon, May 12, 2014 at 7:15 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Sun, May 11, 2014 at 08:52:12PM +0300, Teodora Băluţă wrote:
>> On Sun, May 11, 2014 at 8:18 PM, Levente Kurusa <levex@linux.com> wrote:
>> > 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. :-)
>>
>> That's correct, you still need a click, so maybe a special Android app
>> could do the work so you don't need to turn the compressed oops into
>> base64.
>
> I'd like the URL to be valid (meaning base64 the compressed data) so
> that we can get the data to the kernel.org server as easily as possible.
> Making the app a requirement for reporting is too onerous for
> non-developers.  I see no reason we can't link to (Open in/Install) it
> on the webform though.

So from what I can understand, the QR code has an URL that has the
base64 of the compressed Oops message. Right? I see three problems
with this approach:

- base64 adds about 33% overhead (it's turning 3 octets into 4 encoded
characters + padding). One issue with QR codes is that they have a
limited amount of characters they can hold so that's why I do the
compression in the first place
- besides doing compression in a kernel that's had issues, you add the
base64 encoding inside the kernel
- you would still use a device with a camera (smartphone, tablet) to
scan the QR from the framebuffer, so basically that means an app,
right? What is the point of doing the URL validation inside the kernel
when an app can do that? It doesn't add to the difficulty of sending
the Oops to kernel.org (just one button away)

>
> I see your app as a great tool for people developing the kernel or
> curious about what happened, but there will be a significant number of
> users who don't develop (possibly anything) who won't go to the effort
> to install an app just to help us out.  Knowing how many of those folks
> are affected by the bug is, imho, a very important data point when
> triaging bugs.

Am I missing something here? You still have to scan the QR, right?...
A significant number of users won't have access to the framebuffer to
scan it - the Oops is dumped to the console or inside the
/var/log/dmesg, so the main target is geeky developer people.

>
> Even though these 'users' don't talk on lkml, they *do* exist.  And they
> say mean things like "Linux crashes on my $LAPTOP, it sucks."  I'd rather
> not have to get a facebook account to learn that. :)
>
> thx,
>
> Jason.

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

[Josh Triplett]

On Tue, May 13, 2014 at 09:44:26AM +0300, Teodora Băluţă wrote:
> On Mon, May 12, 2014 at 7:15 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > I'd like the URL to be valid (meaning base64 the compressed data) so
> > that we can get the data to the kernel.org server as easily as possible.
> > Making the app a requirement for reporting is too onerous for
> > non-developers.  I see no reason we can't link to (Open in/Install) it
> > on the webform though.
> 
> So from what I can understand, the QR code has an URL that has the
> base64 of the compressed Oops message. Right? I see three problems
> with this approach:
> 
> - base64 adds about 33% overhead (it's turning 3 octets into 4 encoded
> characters + padding). One issue with QR codes is that they have a
> limited amount of characters they can hold so that's why I do the
> compression in the first place

Putting base64-encoded data in a URL in a binary-format QR code with 8
bits per character does indeed waste quite a bit of space.  However, you
could put base32-encoded data into an alphanumeric-formatted QR code
with 5.5 bits per character, which would waste very little space.  (Or,
more efficiently but less conveniently, base40 or so.)

> - besides doing compression in a kernel that's had issues, you add the
> base64 encoding inside the kernel
> - you would still use a device with a camera (smartphone, tablet) to
> scan the QR from the framebuffer, so basically that means an app,
> right? What is the point of doing the URL validation inside the kernel
> when an app can do that? It doesn't add to the difficulty of sending
> the Oops to kernel.org (just one button away)

Many users will already have a QR-code scanning app installed, and such
apps always support loading URLs in a browser.

Another possibility to consider: current mobile browsers support the
HTML Media Capture API, which allows capturing an image from the camera
from within a file upload control.  Together with a bit of Javascript,
that would allow app-less oops capturing just by visiting a page and
using that page to capture the oops image.

- Josh Triplett

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

[Levente Kurusa]

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

Hi,

On Tue, May 13, 2014 at 12:08:51AM -0700, Josh Triplett wrote:
> On Tue, May 13, 2014 at 09:44:26AM +0300, Teodora Băluţă wrote:
> > On Mon, May 12, 2014 at 7:15 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > > I'd like the URL to be valid (meaning base64 the compressed data) so
> > > that we can get the data to the kernel.org server as easily as possible.
> > > Making the app a requirement for reporting is too onerous for
> > > non-developers.  I see no reason we can't link to (Open in/Install) it
> > > on the webform though.
> > 
> > So from what I can understand, the QR code has an URL that has the
> > base64 of the compressed Oops message. Right? I see three problems
> > with this approach:
> > 
> > - base64 adds about 33% overhead (it's turning 3 octets into 4 encoded
> > characters + padding). One issue with QR codes is that they have a
> > limited amount of characters they can hold so that's why I do the
> > compression in the first place
> 
> Putting base64-encoded data in a URL in a binary-format QR code with 8
> bits per character does indeed waste quite a bit of space.  However, you
> could put base32-encoded data into an alphanumeric-formatted QR code
> with 5.5 bits per character, which would waste very little space.  (Or,
> more efficiently but less conveniently, base40 or so.)
> 

Base32 does sound good until you realize that it requires roughly 20%
more space than Base64 does. We would need some calculations to
decide if we were to go down this path.

> > - besides doing compression in a kernel that's had issues, you add the
> > base64 encoding inside the kernel
> > - you would still use a device with a camera (smartphone, tablet) to
> > scan the QR from the framebuffer, so basically that means an app,
> > right? What is the point of doing the URL validation inside the kernel
> > when an app can do that? It doesn't add to the difficulty of sending
> > the Oops to kernel.org (just one button away)
> 
> Many users will already have a QR-code scanning app installed, and such
> apps always support loading URLs in a browser.
> 

Yes, and having them the requirement of installing an app might make
people turn their heads away from reporting the bug.

> Another possibility to consider: current mobile browsers support the
> HTML Media Capture API, which allows capturing an image from the camera
> from within a file upload control.  Together with a bit of Javascript,
> that would allow app-less oops capturing just by visiting a page and
> using that page to capture the oops image.

I guess this is another way to go provided that devices really do
support it. As far as my device goes it's totally not working. :-)
(Android 2.3.7)

Thanks,
    Levente Kurusa

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

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

[Andy Lutomirski]

On Tue, May 13, 2014 at 8:52 AM, Levente Kurusa <levex@linux.com> wrote:
> Hi,
>
> On Tue, May 13, 2014 at 12:08:51AM -0700, Josh Triplett wrote:
>> On Tue, May 13, 2014 at 09:44:26AM +0300, Teodora Băluţă wrote:
>> > On Mon, May 12, 2014 at 7:15 PM, Jason Cooper <jason@lakedaemon.net> wrote:
>> > > I'd like the URL to be valid (meaning base64 the compressed data) so
>> > > that we can get the data to the kernel.org server as easily as possible.
>> > > Making the app a requirement for reporting is too onerous for
>> > > non-developers.  I see no reason we can't link to (Open in/Install) it
>> > > on the webform though.
>> >
>> > So from what I can understand, the QR code has an URL that has the
>> > base64 of the compressed Oops message. Right? I see three problems
>> > with this approach:
>> >
>> > - base64 adds about 33% overhead (it's turning 3 octets into 4 encoded
>> > characters + padding). One issue with QR codes is that they have a
>> > limited amount of characters they can hold so that's why I do the
>> > compression in the first place
>>
>> Putting base64-encoded data in a URL in a binary-format QR code with 8
>> bits per character does indeed waste quite a bit of space.  However, you
>> could put base32-encoded data into an alphanumeric-formatted QR code
>> with 5.5 bits per character, which would waste very little space.  (Or,
>> more efficiently but less conveniently, base40 or so.)
>>
>
> Base32 does sound good until you realize that it requires roughly 20%
> more space than Base64 does. We would need some calculations to
> decide if we were to go down this path.

I think the idea is that base32 requires 20% more *characters* than
base64, but it also enables the use of alphanumeric QR codes, which
can store more characters for the same number of pixels.

--Andy

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

[josh]

On Tue, May 13, 2014 at 05:52:07PM +0200, Levente Kurusa wrote:
> Hi,
> 
> On Tue, May 13, 2014 at 12:08:51AM -0700, Josh Triplett wrote:
> > On Tue, May 13, 2014 at 09:44:26AM +0300, Teodora Băluţă wrote:
> > > On Mon, May 12, 2014 at 7:15 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > > > I'd like the URL to be valid (meaning base64 the compressed data) so
> > > > that we can get the data to the kernel.org server as easily as possible.
> > > > Making the app a requirement for reporting is too onerous for
> > > > non-developers.  I see no reason we can't link to (Open in/Install) it
> > > > on the webform though.
> > > 
> > > So from what I can understand, the QR code has an URL that has the
> > > base64 of the compressed Oops message. Right? I see three problems
> > > with this approach:
> > > 
> > > - base64 adds about 33% overhead (it's turning 3 octets into 4 encoded
> > > characters + padding). One issue with QR codes is that they have a
> > > limited amount of characters they can hold so that's why I do the
> > > compression in the first place
> > 
> > Putting base64-encoded data in a URL in a binary-format QR code with 8
> > bits per character does indeed waste quite a bit of space.  However, you
> > could put base32-encoded data into an alphanumeric-formatted QR code
> > with 5.5 bits per character, which would waste very little space.  (Or,
> > more efficiently but less conveniently, base40 or so.)
> 
> Base32 does sound good until you realize that it requires roughly 20%
> more space than Base64 does. We would need some calculations to
> decide if we were to go down this path.

QR has several encoding modes; it doesn't matter that base32 uses more
space in terms of characters, because QR itself has an alphanumeric
encoding mode that only uses 5.5 bits per character to encode 45
possible alphanumeric/symbol characters.  base64 wastes far more
relative to bytes (6 versus 8 bits) than base32 wastes relative to QR
alphanumeric (5 versus 5.5 bits).

- Josh Triplett

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

[Johannes Berg]

On Tue, 2014-05-13 at 13:18 -0700, josh@joshtriplett.org wrote:

> > Base32 does sound good until you realize that it requires roughly 20%
> > more space than Base64 does. We would need some calculations to
> > decide if we were to go down this path.
> 
> QR has several encoding modes; it doesn't matter that base32 uses more
> space in terms of characters, because QR itself has an alphanumeric
> encoding mode that only uses 5.5 bits per character to encode 45
> possible alphanumeric/symbol characters.  base64 wastes far more
> relative to bytes (6 versus 8 bits) than base32 wastes relative to QR
> alphanumeric (5 versus 5.5 bits).

This subthread is kinda going on a tangent now, but ...

The valid characters seem to be

0-9A-Z $%*+-./:

so you'll need to be careful to not use a ? for URL parameters [1],
otherwise the QR encoder will likely have to pick binary/byte encoding.

Since you really wouldn't want to use % due to URL-encoding
difficulties, and $ and space also seem a bit questionable, you could
still extend the encoding alphabet to at least base36 (0-9A-Z) and even
add +-./: without much difficulty to get to base41.

johannes

[1] i.e. the previously suggested https://oops.kernel.org/?qr=... will
not work

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

[Josh Triplett]

On Wed, May 14, 2014 at 10:20:52AM +0200, Johannes Berg wrote:
> On Tue, 2014-05-13 at 13:18 -0700, josh@joshtriplett.org wrote:
> 
> > > Base32 does sound good until you realize that it requires roughly 20%
> > > more space than Base64 does. We would need some calculations to
> > > decide if we were to go down this path.
> > 
> > QR has several encoding modes; it doesn't matter that base32 uses more
> > space in terms of characters, because QR itself has an alphanumeric
> > encoding mode that only uses 5.5 bits per character to encode 45
> > possible alphanumeric/symbol characters.  base64 wastes far more
> > relative to bytes (6 versus 8 bits) than base32 wastes relative to QR
> > alphanumeric (5 versus 5.5 bits).
> 
> This subthread is kinda going on a tangent now, but ...
> 
> The valid characters seem to be
> 
> 0-9A-Z $%*+-./:
> 
> so you'll need to be careful to not use a ? for URL parameters [1],
> [1] i.e. the previously suggested https://oops.kernel.org/?qr=... will
> not work

https://oops.kernel.org/qr/...
Or:
https://qr.kernel.org/...

> Since you really wouldn't want to use % due to URL-encoding
> difficulties, and $ and space also seem a bit questionable, you could
> still extend the encoding alphabet to at least base36 (0-9A-Z) and even
> add +-./: without much difficulty to get to base41.

space and % seem like the only ones that need avoiding, both because of
URL-encoding issues; you could use all six of $*+-./: , giving 43 of 45
possible characters.  On the other hand, is it worth the complexity of
using base43 encoding rather than base32?

- Josh Triplett

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

[H. Peter Anvin]

On 05/13/2014 12:08 AM, Josh Triplett wrote:
> 
> Many users will already have a QR-code scanning app installed, and such
> apps always support loading URLs in a browser.
> 

Let me disavow you of the notion that stock scanning apps handle large
QR symbols.

	-hpa

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

[Andy Lutomirski]

On Wed, May 14, 2014 at 9:00 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/13/2014 12:08 AM, Josh Triplett wrote:
>>
>> Many users will already have a QR-code scanning app installed, and such
>> apps always support loading URLs in a browser.
>>
>
> Let me disavow you of the notion that stock scanning apps handle large
> QR symbols.

zxing can handle the bloody enormous QR code here:

http://en.wikipedia.org/wiki/File:Qr-code-ver-40.png

I'll admit that it took a while to find exactly the right camera
position to get it to focus well enough :)

Anyway, point taken: it probably pays to keep the total size of this
thing under control.

--Andy

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

[Josh Triplett]

On Wed, May 14, 2014 at 09:00:51AM -0700, H. Peter Anvin wrote:
> On 05/13/2014 12:08 AM, Josh Triplett wrote:
> > 
> > Many users will already have a QR-code scanning app installed, and such
> > apps always support loading URLs in a browser.
> > 
> 
> Let me disavow you of the notion that stock scanning apps handle large
> QR symbols.

That's certainly true.  On the other hand, I'd really like to see a
version of the oops-as-QR-code bits that uses VGA block characters to
work in non-graphics, non-framebuffer mode, which would require fitting
in at most 80x50 (using the half-block characters).  That wouldn't allow
nearly as much data, but likely enough for a somewhat useful crash
report, especially in aggregate.

- Josh Triplett

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

[Levente Kurusa]

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

On Wed, May 14, 2014 at 11:54:49AM -0700, Josh Triplett wrote:
> On Wed, May 14, 2014 at 09:00:51AM -0700, H. Peter Anvin wrote:
> > On 05/13/2014 12:08 AM, Josh Triplett wrote:
> > > 
> > > Many users will already have a QR-code scanning app installed, and such
> > > apps always support loading URLs in a browser.
> > > 
> > 
> > Let me disavow you of the notion that stock scanning apps handle large
> > QR symbols.
> 
> That's certainly true.  On the other hand, I'd really like to see a
> version of the oops-as-QR-code bits that uses VGA block characters to
> work in non-graphics, non-framebuffer mode, which would require fitting
> in at most 80x50 (using the half-block characters).  That wouldn't allow
> nearly as much data, but likely enough for a somewhat useful crash
> report, especially in aggregate.

Not really possible, from my experiences the QR code that results from
a random oops is ranging from 100x100 to 150x150 depending on the size
of stack trace and stuff like that. Of course, we can decrease the
error recovery region and that might make it smaller. I'll take a look
at this a bit later. If that doesn't work, then that means that we can't
shuffle that into the textmode's 80x25. Not to mention that the block
characters in the ASCII table (I think you meant that, if not please
correct me) are not neccessarily square, which is needed for maximum
scannability.

One thing that we currently support and can be a solution is Micro QR
code. It removes two of the three coordinators and does some more
compression AFAIK. It might be possible to shuffle that into textmode.

I as well would love to support QR codes in textmode, but I think that
it's really not possible at the moment.

Thanks,
    Levente Kurusa

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

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

[Daniel Vetter]

On Wed, May 14, 2014 at 10:00 PM, Levente Kurusa <levex@linux.com> wrote:
> On Wed, May 14, 2014 at 11:54:49AM -0700, Josh Triplett wrote:
>> On Wed, May 14, 2014 at 09:00:51AM -0700, H. Peter Anvin wrote:
>> > On 05/13/2014 12:08 AM, Josh Triplett wrote:
>> > >
>> > > Many users will already have a QR-code scanning app installed, and such
>> > > apps always support loading URLs in a browser.
>> > >
>> >
>> > Let me disavow you of the notion that stock scanning apps handle large
>> > QR symbols.
>>
>> That's certainly true.  On the other hand, I'd really like to see a
>> version of the oops-as-QR-code bits that uses VGA block characters to
>> work in non-graphics, non-framebuffer mode, which would require fitting
>> in at most 80x50 (using the half-block characters).  That wouldn't allow
>> nearly as much data, but likely enough for a somewhat useful crash
>> report, especially in aggregate.
>
> Not really possible, from my experiences the QR code that results from
> a random oops is ranging from 100x100 to 150x150 depending on the size
> of stack trace and stuff like that. Of course, we can decrease the
> error recovery region and that might make it smaller. I'll take a look
> at this a bit later. If that doesn't work, then that means that we can't
> shuffle that into the textmode's 80x25. Not to mention that the block
> characters in the ASCII table (I think you meant that, if not please
> correct me) are not neccessarily square, which is needed for maximum
> scannability.
>
> One thing that we currently support and can be a solution is Micro QR
> code. It removes two of the three coordinators and does some more
> compression AFAIK. It might be possible to shuffle that into textmode.
>
> I as well would love to support QR codes in textmode, but I think that
> it's really not possible at the moment.

David Herrman is working on some new infrastructure for emergency log
services on top of drm/kms drivers since we really, really want to
move away from the horrors called fbcon. His design is fairly neat and
there shouldn't be that big an issue with replacing the current
character-painting code he has with some oops-painting code. Adding
him to the discussion so he can point at some of the patches.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[David Herrmann]

Hi

On Wed, May 14, 2014 at 10:24 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, May 14, 2014 at 10:00 PM, Levente Kurusa <levex@linux.com> wrote:
>> I as well would love to support QR codes in textmode, but I think that
>> it's really not possible at the moment.
>
> David Herrman is working on some new infrastructure for emergency log
> services on top of drm/kms drivers since we really, really want to
> move away from the horrors called fbcon. His design is fairly neat and
> there shouldn't be that big an issue with replacing the current
> character-painting code he has with some oops-painting code. Adding
> him to the discussion so he can point at some of the patches.

Still working on that, but I have no public tree for it right now. The
design basically asks all registered graphics driver for a
kernel-mapped framebuffer and the current mode/format. In case the
current FB is not / cannot be mapped, we try to flip to a fallback
buffer with the same mode/format. If even that fails, we try to do a
full modeset and DPMS stuff and more (this is all the responsibility
of the driver).
To avoid expensive call-paths, we do this step-by-step: first all
drivers are asked for the current FB and we render on all successfull
mappings. Then we continue with the remaining drivers and the
remaining options, and so on..

Note that setting a modern DRM driver into text-mode is far more
expensive than asking for the current FB. This is even mostly true for
any VESA-compatible card (through SimpleDRM). So I don't see why
anyone should bother using textmode for QR codes (but if you think
that's fun, I won't stop you).

The kernel-core will see one function, drm_render_oops() (or something
similar), which will try to do its best to render on all screens.
Default mode is rendering the kernel-log (through drm_log), but any
other stuff like QR is possible. There's a helper called
drm_draw_pixel() that can draw pixels in _any_ RGB format (maybe even
YUV and stuff), so the renderers don't even have to deal with DRM
formats.

I will show a prototype at LPC14, if anyone is interested.
David

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

[Josh Triplett]

On Wed, May 14, 2014 at 10:00:43PM +0200, Levente Kurusa wrote:
> On Wed, May 14, 2014 at 11:54:49AM -0700, Josh Triplett wrote:
> > On Wed, May 14, 2014 at 09:00:51AM -0700, H. Peter Anvin wrote:
> > > On 05/13/2014 12:08 AM, Josh Triplett wrote:
> > > > 
> > > > Many users will already have a QR-code scanning app installed, and such
> > > > apps always support loading URLs in a browser.
> > > > 
> > > 
> > > Let me disavow you of the notion that stock scanning apps handle large
> > > QR symbols.
> > 
> > That's certainly true.  On the other hand, I'd really like to see a
> > version of the oops-as-QR-code bits that uses VGA block characters to
> > work in non-graphics, non-framebuffer mode, which would require fitting
> > in at most 80x50 (using the half-block characters).  That wouldn't allow
> > nearly as much data, but likely enough for a somewhat useful crash
> > report, especially in aggregate.
> 
> Not really possible, from my experiences the QR code that results from
> a random oops is ranging from 100x100 to 150x150 depending on the size
> of stack trace and stuff like that. Of course, we can decrease the
> error recovery region and that might make it smaller. I'll take a look
> at this a bit later. If that doesn't work, then that means that we can't
> shuffle that into the textmode's 80x25. Not to mention that the block
> characters in the ASCII table (I think you meant that, if not please
> correct me) are not neccessarily square, which is needed for maximum
> scannability.

In the standard EGA/VGA/DOS character font, see characters DB (solid
block), DC (lower half block), and DF (upper half block).  Those allow
drawing 80x50 on an 80x25 console.  Unicode has those as well, and also
supports a full set of quarter-character blocks which would allow
160x50; see U+2580 through U+259F.

I've also seen discussions about removing less useful information from
the oops backtrace (simplifying it to just the backtrace itself, and
less of the guessed-at information).

> One thing that we currently support and can be a solution is Micro QR
> code. It removes two of the three coordinators and does some more
> compression AFAIK. It might be possible to shuffle that into textmode.

How widely do stock barcode reader apps support that?

- Josh Triplett

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

[Levente Kurusa]

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

Hi,

On Wed, May 14, 2014 at 03:55:23PM -0700, Josh Triplett wrote:
> On Wed, May 14, 2014 at 10:00:43PM +0200, Levente Kurusa wrote:
> > On Wed, May 14, 2014 at 11:54:49AM -0700, Josh Triplett wrote:
> > > On Wed, May 14, 2014 at 09:00:51AM -0700, H. Peter Anvin wrote:
> > > > On 05/13/2014 12:08 AM, Josh Triplett wrote:
> > > > > 
> > > > > Many users will already have a QR-code scanning app installed, and such
> > > > > apps always support loading URLs in a browser.
> > > > > 
> > > > 
> > > > Let me disavow you of the notion that stock scanning apps handle large
> > > > QR symbols.
> > > 
> > > That's certainly true.  On the other hand, I'd really like to see a
> > > version of the oops-as-QR-code bits that uses VGA block characters to
> > > work in non-graphics, non-framebuffer mode, which would require fitting
> > > in at most 80x50 (using the half-block characters).  That wouldn't allow
> > > nearly as much data, but likely enough for a somewhat useful crash
> > > report, especially in aggregate.
> > 
> > Not really possible, from my experiences the QR code that results from
> > a random oops is ranging from 100x100 to 150x150 depending on the size
> > of stack trace and stuff like that. Of course, we can decrease the
> > error recovery region and that might make it smaller. I'll take a look
> > at this a bit later. If that doesn't work, then that means that we can't
> > shuffle that into the textmode's 80x25. Not to mention that the block
> > characters in the ASCII table (I think you meant that, if not please
> > correct me) are not neccessarily square, which is needed for maximum
> > scannability.
> 
> In the standard EGA/VGA/DOS character font, see characters DB (solid
> block), DC (lower half block), and DF (upper half block).  Those allow
> drawing 80x50 on an 80x25 console.  Unicode has those as well, and also
> supports a full set of quarter-character blocks which would allow
> 160x50; see U+2580 through U+259F.
> 

Hm, I see. I'll find some time soon to check on this.

> I've also seen discussions about removing less useful information from
> the oops backtrace (simplifying it to just the backtrace itself, and
> less of the guessed-at information).

Indeed, that might as well make the QR code smaller. I was thinking
about what really is the point in having the registers in the QR code
as well. I guess that is something we could leave out, right?

> 
> > One thing that we currently support and can be a solution is Micro QR
> > code. It removes two of the three coordinators and does some more
> > compression AFAIK. It might be possible to shuffle that into textmode.
> 
> How widely do stock barcode reader apps support that?

No idea, but, sadly, mine does not support MicroQR. (At least it was
not able to read the MicroQR example found on Wikipedia). I have
NeoReader as a stock scanner.

Thanks,
    Levente Kurusa

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

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

[H. Peter Anvin]

On 05/15/2014 05:44 AM, Levente Kurusa wrote:
> 
> Indeed, that might as well make the QR code smaller. I was
> thinking about what really is the point in having the registers in
> the QR code as well. I guess that is something we could leave out,
> right?
> 

HELL NO.

	-hpa

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

[H. Peter Anvin]

On 05/14/2014 11:54 AM, Josh Triplett wrote:
> 
> That's certainly true.  On the other hand, I'd really like to see a
> version of the oops-as-QR-code bits that uses VGA block characters to
> work in non-graphics, non-framebuffer mode, which would require fitting
> in at most 80x50 (using the half-block characters).  That wouldn't allow
> nearly as much data, but likely enough for a somewhat useful crash
> report, especially in aggregate.
> 

Now we're getting into a funny area, which is "what is the lowest common
denominator".  If the lowest common denominator is VGA, a simple VGA
driver could force the screen to 640x480 graphics mode, or reprogram the
font to allow for an 160x100 pixel pseudographic mode (more if we allow
the font size to be adjusted).  It is not at all clear that using IBM
pseudographics with no other programming is a useful point on that spectrum.

Either way, this is *way* past turning into a technical conversation,
and belongs on LKML and not ksummit-discuss.

	-hpa

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

[Levente Kurusa]

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

Hi,

On Thu, May 15, 2014 at 12:18:27PM -0700, H. Peter Anvin wrote:
> On 05/14/2014 11:54 AM, Josh Triplett wrote:
> > 
> > That's certainly true.  On the other hand, I'd really like to see a
> > version of the oops-as-QR-code bits that uses VGA block characters to
> > work in non-graphics, non-framebuffer mode, which would require fitting
> > in at most 80x50 (using the half-block characters).  That wouldn't allow
> > nearly as much data, but likely enough for a somewhat useful crash
> > report, especially in aggregate.
> > 
> 
> Now we're getting into a funny area, which is "what is the lowest common
> denominator".  If the lowest common denominator is VGA, a simple VGA
> driver could force the screen to 640x480 graphics mode, or reprogram the
> font to allow for an 160x100 pixel pseudographic mode (more if we allow
> the font size to be adjusted).  It is not at all clear that using IBM
> pseudographics with no other programming is a useful point on that spectrum.
> 
> Either way, this is *way* past turning into a technical conversation,
> and belongs on LKML and not ksummit-discuss.
> 

Right, I'll write up what technical stuff we discussed here and post
it on LKML in the RFC thread so we can get rid of the tech discussions
here.

Thanks,
    Levente Kurusa

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

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

[David Woodhouse]

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

On Mon, 2014-05-12 at 12:15 -0400, Jason Cooper wrote:
> On Sun, May 11, 2014 at 08:52:12PM +0300, Teodora Băluţă wrote:
> > On Sun, May 11, 2014 at 8:18 PM, Levente Kurusa <levex@linux.com> wrote:
> > > 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. :-)
> > 
> > That's correct, you still need a click, so maybe a special Android app
> > could do the work so you don't need to turn the compressed oops into
> > base64.
> 
> I'd like the URL to be valid (meaning base64 the compressed data) so
> that we can get the data to the kernel.org server as easily as possible.
> Making the app a requirement for reporting is too onerous for
> non-developers.  I see no reason we can't link to (Open in/Install) it
> on the webform though.
> 
> I see your app as a great tool for people developing the kernel or
> curious about what happened, but there will be a significant number of
> users who don't develop (possibly anything) who won't go to the effort
> to install an app just to help us out.  Knowing how many of those folks
> are affected by the bug is, imho, a very important data point when
> triaging bugs.

With smart Internet-connected TVs and monitors, can't we embed the app
in the monitor itself, and have it upload the oops? Why use a
camera...? :)

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

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

[H. Peter Anvin]

On 05/13/2014 07:45 AM, David Woodhouse wrote:
> 
> With smart Internet-connected TVs and monitors, can't we embed the app
> in the monitor itself, and have it upload the oops? Why use a
> camera...? :)
> 

The whole point of doing this is for dealing with devices which don't
have any kind of reasonable path to the Internet.

If you have a device that can take a perfect screenshot, there are *way*
better ways to use that than making a QR code, and if there is another
path to the outside world, it is probably a lot better.

	-hpa (who is suddenly thinking extremely evil thoughts about
              modem tones and sound cards.)

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

[Jiri Kosina]

On Thu, 15 May 2014, H. Peter Anvin wrote:

> 	-hpa (who is suddenly thinking extremely evil thoughts about
>               modem tones and sound cards.)

I recall a patchset flying by years ago, which could use either keyboard 
LEDs or pc speaker to provide the oops to in morse code.

It's now more difficult with USB keyboards, because you need a lot of 
stuff to happen (including scheduling a workqueue) to blink the LEDs, but 
the pc speaker part should work.

Then you just run an app on your smartphone which decodes the morse back 
to the actual oops message, and you are done :)

-- 
Jiri Kosina
SUSE Labs

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

[Jason Cooper]

On Sun, May 11, 2014 at 07:18:24PM +0200, Levente Kurusa wrote:
> 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:
...
> > > 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)

Agree.

> I guess we should also be careful with the bugzilla. We really don't
> want propertiary driver crashes added to the bugzilla automatically.

Correct, but the data is still worth recording.

> Nor do we want the same oops added twice, right?

We don't want two bugzilla entries, but we do want to know how many
times this event has happened.

> How would we differentiate between the two - essentially the same -
> oopses?

Hmm, oops cookie?  hex string of 32/64 bits read off of the entropy
pool?  This would give us an accurate number of events even if a user
scans multiple times.

thx,

Jason.

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

[Levente Kurusa]

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

Hi,

On Mon, May 12, 2014 at 11:53:20AM -0400, Jason Cooper wrote:
> On Sun, May 11, 2014 at 07:18:24PM +0200, Levente Kurusa wrote:
> > 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:
> ...
> > > > 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)
> 
> Agree.
> 
> > I guess we should also be careful with the bugzilla. We really don't
> > want propertiary driver crashes added to the bugzilla automatically.
> 
> Correct, but the data is still worth recording.
> 
> > Nor do we want the same oops added twice, right?
> 
> We don't want two bugzilla entries, but we do want to know how many
> times this event has happened.
> 
> > How would we differentiate between the two - essentially the same -
> > oopses?
> 
> Hmm, oops cookie?  hex string of 32/64 bits read off of the entropy
> pool?  This would give us an accurate number of events even if a user
> scans multiple times.

Hmm, I've been wondering about this too. I guess 32 bits are enough to
differentiate between oopses, and adding this to the QR code is
relatively easy as well.

What I wonder is how could we get the server back-end to not
allow the same oopses from bad users.

Having a link like:

oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA

would mean that malicious users could edit the $ENTROPY part and
hence effectively report the same oops twice. Maybe some checksum?
Or will it be too much for an already damaged kernel?

Thanks,
    Levente Kurusa

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

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

[H. Peter Anvin]

On 05/12/2014 09:49 AM, Levente Kurusa wrote:
> 
> What I wonder is how could we get the server back-end to not allow 
> the same oopses from bad users.
> 
> Having a link like:
> 
> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
> 
> would mean that malicious users could edit the $ENTROPY part and 
> hence effectively report the same oops twice. Maybe some checksum?
>  Or will it be too much for an already damaged kernel?
> 

What did the old kerneloops system do for these kinds of things?

Again, I'm concerned that a KS session for this will turn into an
implementation discussion, which is better done by email.

	-hpa

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

[Teodora Băluţă]

On Mon, May 12, 2014 at 8:09 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/12/2014 09:49 AM, Levente Kurusa wrote:
>>
>> What I wonder is how could we get the server back-end to not allow
>> the same oopses from bad users.
>>
>> Having a link like:
>>
>> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
>>
>> would mean that malicious users could edit the $ENTROPY part and
>> hence effectively report the same oops twice. Maybe some checksum?
>>  Or will it be too much for an already damaged kernel?
>>
>
> What did the old kerneloops system do for these kinds of things?
>
> Again, I'm concerned that a KS session for this will turn into an
> implementation discussion, which is better done by email.

Well, the discussion got a bit technical, but as Josh said, I see no
point in doing that sort of talk (for technical discussion there's
always the RFC thread [0]). I think what would be of interest is the
way the workflow changes and the infrastructure you need to maintain.
For example, at the moment, can you actually send an Oops directly to
kernel.org by posting it in a query?

Thanks,
Teodora

[0] https://lkml.org/lkml/2014/3/17/525

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

[Greg KH]

On Mon, May 12, 2014 at 08:50:27PM +0300, Teodora Băluţă wrote:
> On Mon, May 12, 2014 at 8:09 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 05/12/2014 09:49 AM, Levente Kurusa wrote:
> >>
> >> What I wonder is how could we get the server back-end to not allow
> >> the same oopses from bad users.
> >>
> >> Having a link like:
> >>
> >> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
> >>
> >> would mean that malicious users could edit the $ENTROPY part and
> >> hence effectively report the same oops twice. Maybe some checksum?
> >>  Or will it be too much for an already damaged kernel?
> >>
> >
> > What did the old kerneloops system do for these kinds of things?
> >
> > Again, I'm concerned that a KS session for this will turn into an
> > implementation discussion, which is better done by email.
> 
> Well, the discussion got a bit technical, but as Josh said, I see no
> point in doing that sort of talk (for technical discussion there's
> always the RFC thread [0]). I think what would be of interest is the
> way the workflow changes and the infrastructure you need to maintain.
> For example, at the moment, can you actually send an Oops directly to
> kernel.org by posting it in a query?

That is what the kerneloops.org site is for, please use that for stuff
like "automated oops reports", not bugzilla.kernel.org, as that is not
going to work at all.

thanks,

greg k-h

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

[Sarah A Sharp]

On Tue, May 13, 2014 at 4:25 AM, Greg KH <greg@kroah.com> wrote:
> On Mon, May 12, 2014 at 08:50:27PM +0300, Teodora Băluţă wrote:
>> On Mon, May 12, 2014 at 8:09 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> > On 05/12/2014 09:49 AM, Levente Kurusa wrote:
>> >>
>> >> What I wonder is how could we get the server back-end to not allow
>> >> the same oopses from bad users.
>> >>
>> >> Having a link like:
>> >>
>> >> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
>> >>
>> >> would mean that malicious users could edit the $ENTROPY part and
>> >> hence effectively report the same oops twice. Maybe some checksum?
>> >>  Or will it be too much for an already damaged kernel?
>> >>
>> >
>> > What did the old kerneloops system do for these kinds of things?
>> >
>> > Again, I'm concerned that a KS session for this will turn into an
>> > implementation discussion, which is better done by email.
>>
>> Well, the discussion got a bit technical, but as Josh said, I see no
>> point in doing that sort of talk (for technical discussion there's
>> always the RFC thread [0]). I think what would be of interest is the
>> way the workflow changes and the infrastructure you need to maintain.
>> For example, at the moment, can you actually send an Oops directly to
>> kernel.org by posting it in a query?
>
> That is what the kerneloops.org site is for, please use that for stuff
> like "automated oops reports", not bugzilla.kernel.org, as that is not
> going to work at all.

It's clear that by default, any oops reported through the QR code
generator should be reported to kerneloops.org.  Do you think there's
additional value in *optionally* allowing someone to file a bugzilla
report against that oops, or do you think there's no value in using
bugzilla.kernel.org at all for this project?

Sarah Sharp

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

[Greg KH]

On Tue, May 13, 2014 at 07:41:15AM -0700, Sarah A Sharp wrote:
> On Tue, May 13, 2014 at 4:25 AM, Greg KH <greg@kroah.com> wrote:
> > On Mon, May 12, 2014 at 08:50:27PM +0300, Teodora Băluţă wrote:
> >> On Mon, May 12, 2014 at 8:09 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> >> > On 05/12/2014 09:49 AM, Levente Kurusa wrote:
> >> >>
> >> >> What I wonder is how could we get the server back-end to not allow
> >> >> the same oopses from bad users.
> >> >>
> >> >> Having a link like:
> >> >>
> >> >> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
> >> >>
> >> >> would mean that malicious users could edit the $ENTROPY part and
> >> >> hence effectively report the same oops twice. Maybe some checksum?
> >> >>  Or will it be too much for an already damaged kernel?
> >> >>
> >> >
> >> > What did the old kerneloops system do for these kinds of things?
> >> >
> >> > Again, I'm concerned that a KS session for this will turn into an
> >> > implementation discussion, which is better done by email.
> >>
> >> Well, the discussion got a bit technical, but as Josh said, I see no
> >> point in doing that sort of talk (for technical discussion there's
> >> always the RFC thread [0]). I think what would be of interest is the
> >> way the workflow changes and the infrastructure you need to maintain.
> >> For example, at the moment, can you actually send an Oops directly to
> >> kernel.org by posting it in a query?
> >
> > That is what the kerneloops.org site is for, please use that for stuff
> > like "automated oops reports", not bugzilla.kernel.org, as that is not
> > going to work at all.
> 
> It's clear that by default, any oops reported through the QR code
> generator should be reported to kerneloops.org.  Do you think there's
> additional value in *optionally* allowing someone to file a bugzilla
> report against that oops, or do you think there's no value in using
> bugzilla.kernel.org at all for this project?

As I don't use bugzilla for kernel stuff, I really don't recommend it.
Espcially if it would give a false sense of "I reported it to the
developers" feeling to users that someone would actually now look at the
issue.

greg k-h

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

[Sarah A Sharp]

On Tue, May 13, 2014 at 8:05 AM, Greg KH <greg@kroah.com> wrote:
> On Tue, May 13, 2014 at 07:41:15AM -0700, Sarah A Sharp wrote:
>> On Tue, May 13, 2014 at 4:25 AM, Greg KH <greg@kroah.com> wrote:
>> > On Mon, May 12, 2014 at 08:50:27PM +0300, Teodora Băluţă wrote:
>> >> On Mon, May 12, 2014 at 8:09 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> >> > On 05/12/2014 09:49 AM, Levente Kurusa wrote:
>> >> >>
>> >> >> What I wonder is how could we get the server back-end to not allow
>> >> >> the same oopses from bad users.
>> >> >>
>> >> >> Having a link like:
>> >> >>
>> >> >> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
>> >> >>
>> >> >> would mean that malicious users could edit the $ENTROPY part and
>> >> >> hence effectively report the same oops twice. Maybe some checksum?
>> >> >>  Or will it be too much for an already damaged kernel?
>> >> >>
>> >> >
>> >> > What did the old kerneloops system do for these kinds of things?
>> >> >
>> >> > Again, I'm concerned that a KS session for this will turn into an
>> >> > implementation discussion, which is better done by email.
>> >>
>> >> Well, the discussion got a bit technical, but as Josh said, I see no
>> >> point in doing that sort of talk (for technical discussion there's
>> >> always the RFC thread [0]). I think what would be of interest is the
>> >> way the workflow changes and the infrastructure you need to maintain.
>> >> For example, at the moment, can you actually send an Oops directly to
>> >> kernel.org by posting it in a query?
>> >
>> > That is what the kerneloops.org site is for, please use that for stuff
>> > like "automated oops reports", not bugzilla.kernel.org, as that is not
>> > going to work at all.
>>
>> It's clear that by default, any oops reported through the QR code
>> generator should be reported to kerneloops.org.  Do you think there's
>> additional value in *optionally* allowing someone to file a bugzilla
>> report against that oops, or do you think there's no value in using
>> bugzilla.kernel.org at all for this project?
>
> As I don't use bugzilla for kernel stuff, I really don't recommend it.
> Espcially if it would give a false sense of "I reported it to the
> developers" feeling to users that someone would actually now look at the
> issue.

And everyone will look at kerneloops.org instead?

There are some maintainers (like Bjorn in PCI) that do use bugzilla.
Other maintainers want people to report bugs to the mailing list.
It's confusing to bug reporters to figure out where to report bugs.

If MAINTAINERS listed either a bugzilla URL or a mailing list email
where bugs should be reported to, that might be helpful to users.  The
phone app could use that file from a recent kernel to figure out
whether to allow the user to report the oops to bugzilla.kernel.org or
to create an email to send to the right mailing list (and make sure
it's a plain text email).

It's these kinds of social aspects of the project that I'd like to see
get discussed at kernel summit.

Sarah Sharp

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

[Josh Boyer]

On Tue, May 13, 2014 at 11:51 AM, Sarah A Sharp <sarah@thesharps.us> wrote:
> On Tue, May 13, 2014 at 8:05 AM, Greg KH <greg@kroah.com> wrote:
>> On Tue, May 13, 2014 at 07:41:15AM -0700, Sarah A Sharp wrote:
>>> On Tue, May 13, 2014 at 4:25 AM, Greg KH <greg@kroah.com> wrote:
>>> > On Mon, May 12, 2014 at 08:50:27PM +0300, Teodora Băluţă wrote:
>>> >> On Mon, May 12, 2014 at 8:09 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> >> > On 05/12/2014 09:49 AM, Levente Kurusa wrote:
>>> >> >>
>>> >> >> What I wonder is how could we get the server back-end to not allow
>>> >> >> the same oopses from bad users.
>>> >> >>
>>> >> >> Having a link like:
>>> >> >>
>>> >> >> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
>>> >> >>
>>> >> >> would mean that malicious users could edit the $ENTROPY part and
>>> >> >> hence effectively report the same oops twice. Maybe some checksum?
>>> >> >>  Or will it be too much for an already damaged kernel?
>>> >> >>
>>> >> >
>>> >> > What did the old kerneloops system do for these kinds of things?
>>> >> >
>>> >> > Again, I'm concerned that a KS session for this will turn into an
>>> >> > implementation discussion, which is better done by email.
>>> >>
>>> >> Well, the discussion got a bit technical, but as Josh said, I see no
>>> >> point in doing that sort of talk (for technical discussion there's
>>> >> always the RFC thread [0]). I think what would be of interest is the
>>> >> way the workflow changes and the infrastructure you need to maintain.
>>> >> For example, at the moment, can you actually send an Oops directly to
>>> >> kernel.org by posting it in a query?
>>> >
>>> > That is what the kerneloops.org site is for, please use that for stuff
>>> > like "automated oops reports", not bugzilla.kernel.org, as that is not
>>> > going to work at all.
>>>
>>> It's clear that by default, any oops reported through the QR code
>>> generator should be reported to kerneloops.org.  Do you think there's
>>> additional value in *optionally* allowing someone to file a bugzilla
>>> report against that oops, or do you think there's no value in using
>>> bugzilla.kernel.org at all for this project?
>>
>> As I don't use bugzilla for kernel stuff, I really don't recommend it.
>> Espcially if it would give a false sense of "I reported it to the
>> developers" feeling to users that someone would actually now look at the
>> issue.
>
> And everyone will look at kerneloops.org instead?
>
> There are some maintainers (like Bjorn in PCI) that do use bugzilla.
> Other maintainers want people to report bugs to the mailing list.
> It's confusing to bug reporters to figure out where to report bugs.
>
> If MAINTAINERS listed either a bugzilla URL or a mailing list email
> where bugs should be reported to, that might be helpful to users.  The
> phone app could use that file from a recent kernel to figure out
> whether to allow the user to report the oops to bugzilla.kernel.org or
> to create an email to send to the right mailing list (and make sure
> it's a plain text email).
>
> It's these kinds of social aspects of the project that I'd like to see
> get discussed at kernel summit.

We have similar dilemmas in Fedora as well.  Our users report bugs in
Red Hat bugzilla, which nobody wants to look at.  So we wind up trying
to forward relevant information upstream, and the individual
preferences of the maintainers is hard to keep track of.  Reducing the
problem to the absurd, we could just screen scrape RHBZ reports and
dump them on LKML, but I really doubt that is going to help anyone.
I'd be interested in discussing the "how/where to report issues"
problem.

josh

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

[Theodore Ts'o]

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)

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?

						- Ted

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

[Levente Kurusa]

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

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?)

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

After all, if the commitee decides that this topic is viable, I would
be happy to participate.

Thanks,
    Levente Kurusa.

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

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

[Teodora Baluta]

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.

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

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

[Levente Kurusa]

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

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

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

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

[Teodora Băluţă]

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

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

[Josh Boyer]

On Tue, May 13, 2014 at 12:07 PM, Theodore Ts'o <tytso@mit.edu> 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.

Yes, agreed.

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

I think that's not really the full answer.  Having that setup would
certainly be beneficial, but it ignores the time delay required to
both 1) actually get kernel releases to large numbers of users, and 2)
find said interesting patterns.

The number of users testing the latest kernel release is certainly
more today than ever, but the bulk of users are still using distro
kernels.  Even with Fedora, Arch, and other distros rebasing rather
quickly, we are still looking at that kernel release hitting the user
base after the merge window is closed for the next version already
(N+1).  That means the upstream kernel developers are off developing
for the release after (N+2).

So if a large number of users starts hitting bugs in version N, and
the upstream developers are already working on changes for N+2,
waiting for interesting patterns to develop is actually increasing the
"cost" to the developers to go back and look at code they did 2
releases ago.  The typical response is "does this recreate on Linus'
latest tree or some subsystem git tree", which is N+1 in this case.
It's a fair request from a developer's perspective, but it's not as
simple for an end user or distro.  Often times they'll try N+1 and hit
a different bug on their system, making it even more confusing to try
and work the original report to conclusion.  (That appears to be Dave
Jones' life in a nutshell with trinity reports at the moment, so it's
not just Aunt Tillie either.)

Often times the bugs are still in N+1 as well, so it's certainly
helpful to report either way.  The areas where we tend to see this
problem aren't in core MM or VFS code, but more in things like
backlights, GPU drivers, wireless drivers, etc.  These aren't trivial
areas to debug or git bisect (which is a nightmare to work and end
user through).  They are also the same areas where we depend on
end-user testing and reporting because of the huge amount of
variability in the hardware itself.  E.g. a change to fix something in
i915 on one machine/chipset seems to inevitably break a different
machine/chipset.

I realize QR codes, kerneloops.org, and things of that nature aren't
going to solve this problem.  That's kind of why I'd like to see it
discussed more broadly, and not assume that it can be automated away.
I'm just concerned that the rate of development today is outpacing our
ability to get the releases into user's hands and get valid and useful
bug reports from them.

josh

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

[Levente Kurusa]

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

Hi,

On Tue, May 13, 2014 at 09:14:48PM -0400, Josh Boyer wrote:
> On Tue, May 13, 2014 at 12:07 PM, Theodore Ts'o <tytso@mit.edu> 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.
> 
> Yes, agreed.
> 
> > 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)
> 
> I think that's not really the full answer.  Having that setup would
> certainly be beneficial, but it ignores the time delay required to
> both 1) actually get kernel releases to large numbers of users, and 2)
> find said interesting patterns.
> 
> The number of users testing the latest kernel release is certainly
> more today than ever, but the bulk of users are still using distro
> kernels.  Even with Fedora, Arch, and other distros rebasing rather
> quickly, we are still looking at that kernel release hitting the user
> base after the merge window is closed for the next version already
> (N+1).  That means the upstream kernel developers are off developing
> for the release after (N+2).
> 
> So if a large number of users starts hitting bugs in version N, and
> the upstream developers are already working on changes for N+2,
> waiting for interesting patterns to develop is actually increasing the
> "cost" to the developers to go back and look at code they did 2
> releases ago.  The typical response is "does this recreate on Linus'
> latest tree or some subsystem git tree", which is N+1 in this case.
> It's a fair request from a developer's perspective, but it's not as
> simple for an end user or distro.  Often times they'll try N+1 and hit
> a different bug on their system, making it even more confusing to try
> and work the original report to conclusion.  (That appears to be Dave
> Jones' life in a nutshell with trinity reports at the moment, so it's
> not just Aunt Tillie either.)
> 
> Often times the bugs are still in N+1 as well, so it's certainly
> helpful to report either way.  The areas where we tend to see this
> problem aren't in core MM or VFS code, but more in things like
> backlights, GPU drivers, wireless drivers, etc.  These aren't trivial
> areas to debug or git bisect (which is a nightmare to work and end
> user through).  They are also the same areas where we depend on
> end-user testing and reporting because of the huge amount of
> variability in the hardware itself.  E.g. a change to fix something in
> i915 on one machine/chipset seems to inevitably break a different
> machine/chipset.

One thing I would add is if a user actually reports a bug on Bugzilla
often times they are able to do a git bisect. What I have observed is
that less tech-savvy people don't even bother with trying to report
the bug nor they would try to do anything to fix it if the bug isn't
that fatal. Of course, ABRT and the like has improved the number of
quality bug reports, but there still exists a number of fatal bugs
that with which we remain less informed. 

Naturally a question arises. How could get technically not-so-capable
people to report bugs? I guess QR codes have become so mainstream
nowadays, that they can provide a solution. What I see nowadays is
that when people see a QR code, they almost automatically try to scan
it. Not to mention when they have nothing else to do as with a kernel
crash. :-)

> 
> I realize QR codes, kerneloops.org, and things of that nature aren't
> going to solve this problem.  That's kind of why I'd like to see it
> discussed more broadly, and not assume that it can be automated away.
> I'm just concerned that the rate of development today is outpacing our
> ability to get the releases into user's hands and get valid and useful
> bug reports from them.

Indeed, by the time the people's favourite distro rebases, we are
already working on a new release. This mostly does not tend to be
a very bad delay with bleeding-edge distros like Arch and Fedora,
but what I am concerned of is what happens with the conservative
distros like Debian. AFAIK, the latest version of Debian is still
shipping the 3.2 stable kernel. If we start receiving reports from the
3.2 kernel, which is N-13 at the moment, then chances are the reports
are less useless, since the subsystems have evolved so much since 3.2.

Thanks,
    Levente Kurusa

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

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

[Josh Boyer]

On Thu, May 15, 2014 at 1:01 PM, Levente Kurusa <levex@linux.com> wrote:
> Hi,
>
> On Tue, May 13, 2014 at 09:14:48PM -0400, Josh Boyer wrote:
>> On Tue, May 13, 2014 at 12:07 PM, Theodore Ts'o <tytso@mit.edu> 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.
>>
>> Yes, agreed.
>>
>> > 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)
>>
>> I think that's not really the full answer.  Having that setup would
>> certainly be beneficial, but it ignores the time delay required to
>> both 1) actually get kernel releases to large numbers of users, and 2)
>> find said interesting patterns.
>>
>> The number of users testing the latest kernel release is certainly
>> more today than ever, but the bulk of users are still using distro
>> kernels.  Even with Fedora, Arch, and other distros rebasing rather
>> quickly, we are still looking at that kernel release hitting the user
>> base after the merge window is closed for the next version already
>> (N+1).  That means the upstream kernel developers are off developing
>> for the release after (N+2).
>>
>> So if a large number of users starts hitting bugs in version N, and
>> the upstream developers are already working on changes for N+2,
>> waiting for interesting patterns to develop is actually increasing the
>> "cost" to the developers to go back and look at code they did 2
>> releases ago.  The typical response is "does this recreate on Linus'
>> latest tree or some subsystem git tree", which is N+1 in this case.
>> It's a fair request from a developer's perspective, but it's not as
>> simple for an end user or distro.  Often times they'll try N+1 and hit
>> a different bug on their system, making it even more confusing to try
>> and work the original report to conclusion.  (That appears to be Dave
>> Jones' life in a nutshell with trinity reports at the moment, so it's
>> not just Aunt Tillie either.)
>>
>> Often times the bugs are still in N+1 as well, so it's certainly
>> helpful to report either way.  The areas where we tend to see this
>> problem aren't in core MM or VFS code, but more in things like
>> backlights, GPU drivers, wireless drivers, etc.  These aren't trivial
>> areas to debug or git bisect (which is a nightmare to work and end
>> user through).  They are also the same areas where we depend on
>> end-user testing and reporting because of the huge amount of
>> variability in the hardware itself.  E.g. a change to fix something in
>> i915 on one machine/chipset seems to inevitably break a different
>> machine/chipset.
>
> One thing I would add is if a user actually reports a bug on Bugzilla
> often times they are able to do a git bisect. What I have observed is
> that less tech-savvy people don't even bother with trying to report
> the bug nor they would try to do anything to fix it if the bug isn't
> that fatal. Of course, ABRT and the like has improved the number of
> quality bug reports, but there still exists a number of fatal bugs
> that with which we remain less informed.

Working daily in Fedora bugzilla would lead me to politely disagree
with you.  Or perhaps note that ABRT is leading to more bug reports,
but less technically inclined users that find bisect confusing.  Even
some of the more technically inclined users tend to ask for pre-built
RPMs for bisect purposes, which isn't particularly easy.

> Naturally a question arises. How could get technically not-so-capable
> people to report bugs? I guess QR codes have become so mainstream
> nowadays, that they can provide a solution. What I see nowadays is

Maybe.  I've yet to see people actually use QR codes for anything, but
the technology certainly exists.

> that when people see a QR code, they almost automatically try to scan
> it. Not to mention when they have nothing else to do as with a kernel
> crash. :-)

We live in amazingly different worlds.

Anyway, my side discussion was not intended to discourage the QR code
progress.  By all means, those interested should pursue that because
anything helps.

>> I realize QR codes, kerneloops.org, and things of that nature aren't
>> going to solve this problem.  That's kind of why I'd like to see it
>> discussed more broadly, and not assume that it can be automated away.
>> I'm just concerned that the rate of development today is outpacing our
>> ability to get the releases into user's hands and get valid and useful
>> bug reports from them.
>
> Indeed, by the time the people's favourite distro rebases, we are
> already working on a new release. This mostly does not tend to be
> a very bad delay with bleeding-edge distros like Arch and Fedora,
> but what I am concerned of is what happens with the conservative
> distros like Debian. AFAIK, the latest version of Debian is still
> shipping the 3.2 stable kernel. If we start receiving reports from the
> 3.2 kernel, which is N-13 at the moment, then chances are the reports
> are less useless, since the subsystems have evolved so much since 3.2.

Right.  Debian is probably the "worst" case scenario here, because
they use a very old kernel but aren't in the same position as the
other users of old kernels, which are the big Enterprise vendors.  The
EL kernels have lots of staff to deal with this problem, so I'm kind
of excluding them from this aspect of the conversation, but Debian is
certainly impacted.

josh

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

[Levente Kurusa]

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

Hi,

On 05/15/2014 07:11 PM, Josh Boyer wrote:
> On Thu, May 15, 2014 at 1:01 PM, Levente Kurusa <levex@linux.com> wrote:
>> Hi,
>>
>> On Tue, May 13, 2014 at 09:14:48PM -0400, Josh Boyer wrote:
>>> On Tue, May 13, 2014 at 12:07 PM, Theodore Ts'o <tytso@mit.edu> 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.
>>>
>>> Yes, agreed.
>>>
>>>> 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)
>>>
>>> I think that's not really the full answer.  Having that setup would
>>> certainly be beneficial, but it ignores the time delay required to
>>> both 1) actually get kernel releases to large numbers of users, and 2)
>>> find said interesting patterns.
>>>
>>> The number of users testing the latest kernel release is certainly
>>> more today than ever, but the bulk of users are still using distro
>>> kernels.  Even with Fedora, Arch, and other distros rebasing rather
>>> quickly, we are still looking at that kernel release hitting the user
>>> base after the merge window is closed for the next version already
>>> (N+1).  That means the upstream kernel developers are off developing
>>> for the release after (N+2).
>>>
>>> So if a large number of users starts hitting bugs in version N, and
>>> the upstream developers are already working on changes for N+2,
>>> waiting for interesting patterns to develop is actually increasing the
>>> "cost" to the developers to go back and look at code they did 2
>>> releases ago.  The typical response is "does this recreate on Linus'
>>> latest tree or some subsystem git tree", which is N+1 in this case.
>>> It's a fair request from a developer's perspective, but it's not as
>>> simple for an end user or distro.  Often times they'll try N+1 and hit
>>> a different bug on their system, making it even more confusing to try
>>> and work the original report to conclusion.  (That appears to be Dave
>>> Jones' life in a nutshell with trinity reports at the moment, so it's
>>> not just Aunt Tillie either.)
>>>
>>> Often times the bugs are still in N+1 as well, so it's certainly
>>> helpful to report either way.  The areas where we tend to see this
>>> problem aren't in core MM or VFS code, but more in things like
>>> backlights, GPU drivers, wireless drivers, etc.  These aren't trivial
>>> areas to debug or git bisect (which is a nightmare to work and end
>>> user through).  They are also the same areas where we depend on
>>> end-user testing and reporting because of the huge amount of
>>> variability in the hardware itself.  E.g. a change to fix something in
>>> i915 on one machine/chipset seems to inevitably break a different
>>> machine/chipset.
>>
>> One thing I would add is if a user actually reports a bug on Bugzilla
>> often times they are able to do a git bisect. What I have observed is
>> that less tech-savvy people don't even bother with trying to report
>> the bug nor they would try to do anything to fix it if the bug isn't
>> that fatal. Of course, ABRT and the like has improved the number of
>> quality bug reports, but there still exists a number of fatal bugs
>> that with which we remain less informed.
> 
> Working daily in Fedora bugzilla would lead me to politely disagree
> with you.  Or perhaps note that ABRT is leading to more bug reports,
> but less technically inclined users that find bisect confusing.  Even
> some of the more technically inclined users tend to ask for pre-built
> RPMs for bisect purposes, which isn't particularly easy.

I guess that more critical issues are reported by more people and chances
are there is at least one who is capable enough to do a bisect. Less
critical issues might go un-bisected, but I guess that is what people call
'collateral damage'.

> 
>> Naturally a question arises. How could get technically not-so-capable
>> people to report bugs? I guess QR codes have become so mainstream
>> nowadays, that they can provide a solution. What I see nowadays is
> 
> Maybe.  I've yet to see people actually use QR codes for anything, but
> the technology certainly exists.

Well, here in Hungary, these QR codes started to in quite a few places.
Today, I saw it on a restaurant's menu, and it forwarded me to a link
where I could see the particular food from any viewpoint. It also
appeared on the back of vehicles, on TV commercials and a lot of other
places.

> 
>> that when people see a QR code, they almost automatically try to scan
>> it. Not to mention when they have nothing else to do as with a kernel
>> crash. :-)
> 
> We live in amazingly different worlds.

It could be that I am surrounded by tech-savvy people, but it's certainly
getting mainstream.

> 
> Anyway, my side discussion was not intended to discourage the QR code
> progress.  By all means, those interested should pursue that because
> anything helps.

Right.

> 
>>> I realize QR codes, kerneloops.org, and things of that nature aren't
>>> going to solve this problem.  That's kind of why I'd like to see it
>>> discussed more broadly, and not assume that it can be automated away.
>>> I'm just concerned that the rate of development today is outpacing our
>>> ability to get the releases into user's hands and get valid and useful
>>> bug reports from them.
>>
>> Indeed, by the time the people's favourite distro rebases, we are
>> already working on a new release. This mostly does not tend to be
>> a very bad delay with bleeding-edge distros like Arch and Fedora,
>> but what I am concerned of is what happens with the conservative
>> distros like Debian. AFAIK, the latest version of Debian is still
>> shipping the 3.2 stable kernel. If we start receiving reports from the
>> 3.2 kernel, which is N-13 at the moment, then chances are the reports
>> are less useless, since the subsystems have evolved so much since 3.2.
> 
> Right.  Debian is probably the "worst" case scenario here, because
> they use a very old kernel but aren't in the same position as the
> other users of old kernels, which are the big Enterprise vendors.  The
> EL kernels have lots of staff to deal with this problem, so I'm kind
> of excluding them from this aspect of the conversation, but Debian is
> certainly impacted.

... and this won't be fixed by QR codes or anything that reports bugs I
guess, since those reports might be only useful to the stable maintainers.
Other maintainers can not be made to remember their code in a way that allows
triaging bugs in version N-13 or so...


Thanks,
    Levente Kurusa


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[PJ Waskiewicz]

Hi Ted,

On Tue, May 13, 2014 at 9:07 AM, Theodore Ts'o <tytso@mit.edu> 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)
>
> 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.

This is where I disagree.  Looking at this thread alone (outside of
the technical discussion itself), many people have different views of
how b) and c) above should be done.  Having a person or team of folks
go off and build this, or rather their view and interpretation of how
to build this, will undoubtedly get pulled to pieces at KS because of
the differing views.  A better use of everyone's time, core kernel
dev's and people working on a) - c), would be to hash out the details
of *what* this should look like, what kernel dev's *want* and *don't
want.*

Also, a big part of the original thought to having this topic at KS is
to get all the right players in one spot, from kernel dev, kernel.org
infrastructure, etc.  The *how* in building this reporting framework
isn't hard, it's the *what* that needs to be hammered out.  And for
something like the QR encoded oops project, it seems to be a missed
opportunity to put it in the kernel, but have no usable framework to
make full use of it.  That's the point of the discussion we're asking
for, is to make sure it *will* be useful and give all the people who
want to see this have a say in how it should be built.  I really don't
think that type of discussion would be terribly effective or efficient
via email.

And let's be fair, I've seen a number of tech topics at previous KS's
that were more proposals of ideas, looking for design direction and
the like.  I don't see how this is any different.

However, I completely agree that the implementation discussion of how
to do the QR encoding, etc., should be kept to the mailing lists.  And
if this topic is included at KS, then I see no reason that the
participants and leader of the discussion couldn't keep the discussion
on-topic.  Is it really that hard?

Based on the pretty large interest in putting this framework together
(based on this thread alone), I really think this would be a very
useful topic to include at KS this year.

Cheers,
-PJ Waskiewicz

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

[Theodore Ts'o]

On Wed, May 14, 2014 at 10:41:10PM -0700, PJ Waskiewicz wrote:
> Also, a big part of the original thought to having this topic at KS is
> to get all the right players in one spot, from kernel dev, kernel.org
> infrastructure, etc.  The *how* in building this reporting framework
> isn't hard, it's the *what* that needs to be hammered out.  And for
> something like the QR encoded oops project, it seems to be a missed
> opportunity to put it in the kernel, but have no usable framework to
> make full use of it.  That's the point of the discussion we're asking
> for, is to make sure it *will* be useful and give all the people who
> want to see this have a say in how it should be built.  I really don't
> think that type of discussion would be terribly effective or efficient
> via email.

I guess I didn't make myself clear.  I agree that the *how* things
should be built is better done via e-mail, or better yet, by the
person actually doing the work.  What I'm trying to push on is whether
we've identified *who* will do all of this work.  Not just the QR
encoding patches, but all of the associated work that is being
proposed in this thread.

					- Ted

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

[Levente Kurusa]

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

Hi Ted,

On 05/15/2014 05:41 PM, Theodore Ts'o wrote:
> On Wed, May 14, 2014 at 10:41:10PM -0700, PJ Waskiewicz wrote:
>> Also, a big part of the original thought to having this topic at KS is
>> to get all the right players in one spot, from kernel dev, kernel.org
>> infrastructure, etc.  The *how* in building this reporting framework
>> isn't hard, it's the *what* that needs to be hammered out.  And for
>> something like the QR encoded oops project, it seems to be a missed
>> opportunity to put it in the kernel, but have no usable framework to
>> make full use of it.  That's the point of the discussion we're asking
>> for, is to make sure it *will* be useful and give all the people who
>> want to see this have a say in how it should be built.  I really don't
>> think that type of discussion would be terribly effective or efficient
>> via email.
> 
> I guess I didn't make myself clear.  I agree that the *how* things
> should be built is better done via e-mail, or better yet, by the
> person actually doing the work.  What I'm trying to push on is whether
> we've identified *who* will do all of this work.  Not just the QR
> encoding patches, but all of the associated work that is being
> proposed in this thread.

Of course we did identify the team. It's me and Teodora. For this QR
encoding work we need a lot of framework work and while at it we could
also tie up some loose ends in the error reporting workflow. I, for
myself, would love to clean up Bugzilla a bit. It has a lot of open bugs
that have been fixed for ages, just for example.

And, as PJ pointed out, we need to discuss what to do, the how in this
question is pretty much optional and can be later discussed in emails,
but I think that discussing what to do by emails when we have a great
opportunity to discuss this at the summit would sound like a waste of
time.

The topic wouldn't be just about QR codes, but more widely about the
error reporting workflow and how it could reach more users, and how
could it provide more information that can help triaging even very old
bugs, as in Debian's case.

Thanks,
    Levente Kurusa.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Theodore Ts'o]

On Sat, May 17, 2014 at 06:36:50PM +0200, Levente Kurusa wrote:
> 
> Of course we did identify the team. It's me and Teodora. For this QR
> encoding work we need a lot of framework work and while at it we could
> also tie up some loose ends in the error reporting workflow. I, for
> myself, would love to clean up Bugzilla a bit. It has a lot of open bugs
> that have been fixed for ages, just for example.

Just to be clear, since my understanding is that you are university
students --- your primary goal is to clean up the QR encoding work,
yes?  Do you anticipate having time to talk about working on some of
the larger, grander suggestions that some people have raised on this
thread?  That is, some kind of web backend to for which these QR's
could be submitted and then analyzed?

Or is what you plan to be focusing on is more tightly focused on the
the actual generation of the QR barcode?  What help would you need in
order to bring the use of the QR barcode to its fullest potential?

Regards,

						- Ted

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

[Levente Kurusa]

Hi Ted,

2014-05-20 16:47 GMT+02:00 Theodore Ts'o <tytso@mit.edu>:
> On Sat, May 17, 2014 at 06:36:50PM +0200, Levente Kurusa wrote:
>>
>> Of course we did identify the team. It's me and Teodora. For this QR
>> encoding work we need a lot of framework work and while at it we could
>> also tie up some loose ends in the error reporting workflow. I, for
>> myself, would love to clean up Bugzilla a bit. It has a lot of open bugs
>> that have been fixed for ages, just for example.
>
> Just to be clear, since my understanding is that you are university
> students --- your primary goal is to clean up the QR encoding work,
> yes?  Do you anticipate having time to talk about working on some of
> the larger, grander suggestions that some people have raised on this
> thread?  That is, some kind of web backend to for which these QR's
> could be submitted and then analyzed?

At first, yes, my primary goal is to clean up the library that we currently
use. We still need to remove a lot of unused crap from the library and
make it behave nicer as in resource usage as well... Regarding the
web-backend. I think Teodora has already started working on something
like that,  but she might be working on the Android app she proposed earlier.

Yes I realize that encoding the oops as a QR code is just a part of what
we really need in order to bring it to its fullest. And I for sure can say I'll
have time to work on the suggestions. I talked with Teodora about this and
she is having her finals, but after that I guess she will join me on this
journey.

> Or is what you plan to be focusing on is more tightly focused on the
> the actual generation of the QR barcode?  What help would you need in
> order to bring the use of the QR barcode to its fullest potential?

No not just the generation. I as a user don't at all find reporting kernel bugs
a pleasure. My goal (and I think Teodora's as well) is to make it better. In the
process we would need to clean up stuff that has gotten rusty over the years.

What we ask for is a discussion, so that we know what work is needed to
be done and what suggestions people have for us.

Thanks,
    Levente Kurusa

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

[Teodora Băluţă]

Hi,

> 2014-05-20 16:47 GMT+02:00 Theodore Ts'o <tytso@mit.edu>:
>> On Sat, May 17, 2014 at 06:36:50PM +0200, Levente Kurusa wrote:
>>>
>>> Of course we did identify the team. It's me and Teodora. For this QR
>>> encoding work we need a lot of framework work and while at it we could
>>> also tie up some loose ends in the error reporting workflow. I, for
>>> myself, would love to clean up Bugzilla a bit. It has a lot of open bugs
>>> that have been fixed for ages, just for example.
>>
>> Just to be clear, since my understanding is that you are university
>> students --- your primary goal is to clean up the QR encoding work,
>> yes?  Do you anticipate having time to talk about working on some of
>> the larger, grander suggestions that some people have raised on this
>> thread?  That is, some kind of web backend to for which these QR's
>> could be submitted and then analyzed?
>
> At first, yes, my primary goal is to clean up the library that we currently
> use. We still need to remove a lot of unused crap from the library and
> make it behave nicer as in resource usage as well... Regarding the
> web-backend. I think Teodora has already started working on something
> like that,  but she might be working on the Android app she proposed earlier.

As a final project for one of my courses we had to implement an
Android app of and since it was open-source and free of choice I chose
to work on something related to the QR/reporting bugs (killing two
birds with one stone). It was a two-person team project (added friend
I worked with at cc)

It is a prototype that includes a simple Android app and a web server.
Basically scan the QR and then send it to the web server or email it.
You may checkout the code at
https://github.com/PDSD-2014/baluta-foianu. I will migrate the project
to my repository soon (now it's it our course's repo).

>
> Yes I realize that encoding the oops as a QR code is just a part of what
> we really need in order to bring it to its fullest. And I for sure can say I'll
> have time to work on the suggestions. I talked with Teodora about this and
> she is having her finals, but after that I guess she will join me on this
> journey.

Yes, finals are fun!... part of the reason I didn't reply for so
long... I have my last exam next Tuesday. I will be working on my
graduation project up to the end of June so I can't work full-time on
this, but I can surely make time and would love to get this up and
running.

>
>> Or is what you plan to be focusing on is more tightly focused on the
>> the actual generation of the QR barcode?  What help would you need in
>> order to bring the use of the QR barcode to its fullest potential?
>
> No not just the generation. I as a user don't at all find reporting kernel bugs
> a pleasure. My goal (and I think Teodora's as well) is to make it better. In the
> process we would need to clean up stuff that has gotten rusty over the years.
>
> What we ask for is a discussion, so that we know what work is needed to
> be done and what suggestions people have for us.
>

I agree. It is always important to know what you want to improve from
different people/perspectives, prioritize and then implement them.
When discussing via email implementation details may become
predominant but actually a discussion on what is our main focus and
compromising is better done in person imho.

Thanks,
Teodora

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

[H. Peter Anvin]

On 05/13/2014 09:07 AM, 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)
> 
> 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?
> 

A workflow discussion for gathering fault information in general *might*
be useful, but I'm not sure we have the right people for it.  As far as
I understand, kerneloops.org pretty much lost its usefulness when Fedora
(and other distros?) stopped participating and redirected to their own
internal sites.

	-hpa

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

[Levente Kurusa]

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

Hi,

On Thu, May 15, 2014 at 12:24:22PM -0700, H. Peter Anvin wrote:
> On 05/13/2014 09:07 AM, 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)
> > 
> > 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?
> > 
> 
> A workflow discussion for gathering fault information in general *might*
> be useful, but I'm not sure we have the right people for it.  As far as
> I understand, kerneloops.org pretty much lost its usefulness when Fedora
> (and other distros?) stopped participating and redirected to their own
> internal sites.

Looking at oops.kernel.org, one of the top guilties is Fedora. Also,
looking at the ABRT FAQ it still seems to send the OOPSes to the site.
So, I guess Fedora didn't stop sending them. But maybe, Josh knows
better?

I am not sure if the site has lost any of its usefulness. It still has
a DB of ~4K oopses in May already. What I think is the problem, is
that maintainers barely look at it. I think there are numerous reasons
behind that, and I see a lot of improvements could be made there.

Regarding the wrong people. While we could not be the best people to
discuss this with, we are the ones, at least I am, who are *willing*
to do some work on the core error reporting and gathering parts of the
kernel.

Thanks,
    Levente Kurusa

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

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

[Greg KH]

On Tue, May 13, 2014 at 08:51:36AM -0700, Sarah A Sharp wrote:
> On Tue, May 13, 2014 at 8:05 AM, Greg KH <greg@kroah.com> wrote:
> > On Tue, May 13, 2014 at 07:41:15AM -0700, Sarah A Sharp wrote:
> >> On Tue, May 13, 2014 at 4:25 AM, Greg KH <greg@kroah.com> wrote:
> >> > On Mon, May 12, 2014 at 08:50:27PM +0300, Teodora Băluţă wrote:
> >> >> On Mon, May 12, 2014 at 8:09 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> >> >> > On 05/12/2014 09:49 AM, Levente Kurusa wrote:
> >> >> >>
> >> >> >> What I wonder is how could we get the server back-end to not allow
> >> >> >> the same oopses from bad users.
> >> >> >>
> >> >> >> Having a link like:
> >> >> >>
> >> >> >> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
> >> >> >>
> >> >> >> would mean that malicious users could edit the $ENTROPY part and
> >> >> >> hence effectively report the same oops twice. Maybe some checksum?
> >> >> >>  Or will it be too much for an already damaged kernel?
> >> >> >>
> >> >> >
> >> >> > What did the old kerneloops system do for these kinds of things?
> >> >> >
> >> >> > Again, I'm concerned that a KS session for this will turn into an
> >> >> > implementation discussion, which is better done by email.
> >> >>
> >> >> Well, the discussion got a bit technical, but as Josh said, I see no
> >> >> point in doing that sort of talk (for technical discussion there's
> >> >> always the RFC thread [0]). I think what would be of interest is the
> >> >> way the workflow changes and the infrastructure you need to maintain.
> >> >> For example, at the moment, can you actually send an Oops directly to
> >> >> kernel.org by posting it in a query?
> >> >
> >> > That is what the kerneloops.org site is for, please use that for stuff
> >> > like "automated oops reports", not bugzilla.kernel.org, as that is not
> >> > going to work at all.
> >>
> >> It's clear that by default, any oops reported through the QR code
> >> generator should be reported to kerneloops.org.  Do you think there's
> >> additional value in *optionally* allowing someone to file a bugzilla
> >> report against that oops, or do you think there's no value in using
> >> bugzilla.kernel.org at all for this project?
> >
> > As I don't use bugzilla for kernel stuff, I really don't recommend it.
> > Espcially if it would give a false sense of "I reported it to the
> > developers" feeling to users that someone would actually now look at the
> > issue.
> 
> And everyone will look at kerneloops.org instead?

I did before, yes, because it makes it easy to see what subsystem is
having issues, and how many people are hitting the same oops.  bugzilla
can't do "merges" of reports, so someone is going to have to sit there
and manually mark bugs as duplicates.  We can't find people do just do
basic bugzilla triage today, who is going to do all of that
de-duplication?

> There are some maintainers (like Bjorn in PCI) that do use bugzilla.
> Other maintainers want people to report bugs to the mailing list.
> It's confusing to bug reporters to figure out where to report bugs.
> 
> If MAINTAINERS listed either a bugzilla URL or a mailing list email
> where bugs should be reported to, that might be helpful to users.

Sounds reasonable, add another MAINTAINERS entry field :)

> The phone app could use that file from a recent kernel to figure out
> whether to allow the user to report the oops to bugzilla.kernel.org or
> to create an email to send to the right mailing list (and make sure
> it's a plain text email).
> 
> It's these kinds of social aspects of the project that I'd like to see
> get discussed at kernel summit.

Again, as hpa stated, that will devolved to a technical discussion at KS
and not really be productive.  Stick to email, we do technical things
really well there.

thanks,

greg k-h

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

[Jason Cooper]

On Mon, May 12, 2014 at 06:49:21PM +0200, Levente Kurusa wrote:
> On Mon, May 12, 2014 at 11:53:20AM -0400, Jason Cooper wrote:
> > On Sun, May 11, 2014 at 07:18:24PM +0200, Levente Kurusa wrote:
...
> > > I guess we should also be careful with the bugzilla. We really don't
> > > want propertiary driver crashes added to the bugzilla automatically.
> > 
> > Correct, but the data is still worth recording.
> > 
> > > Nor do we want the same oops added twice, right?
> > 
> > We don't want two bugzilla entries, but we do want to know how many
> > times this event has happened.
> > 
> > > How would we differentiate between the two - essentially the same -
> > > oopses?
> > 
> > Hmm, oops cookie?  hex string of 32/64 bits read off of the entropy
> > pool?  This would give us an accurate number of events even if a user
> > scans multiple times.
> 
> Hmm, I've been wondering about this too. I guess 32 bits are enough to
> differentiate between oopses, and adding this to the QR code is
> relatively easy as well.

I was thinking directly in the oops.  Never underestimate the tenacity
of a user.  You'll get the qr-code scan, _and_ a bug report filed with a
grainy picture.

> What I wonder is how could we get the server back-end to not
> allow the same oopses from bad users.
> 
> Having a link like:
> 
> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
> 
> would mean that malicious users could edit the $ENTROPY part and
> hence effectively report the same oops twice. Maybe some checksum?
> Or will it be too much for an already damaged kernel?

encoding it in the oops text makes this a lot more difficult.  Plus,
what is the goal of the attacker in this scenario?

thx,

Jason.

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

[Sarah A Sharp]

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

On May 11, 2014 9:37 AM, "Laurent Pinchart" <
laurent.pinchart@ideasonboard.com> 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.

It would be interesting to see if the app could use Google voice
recognition to fill in the text fields. Even just partially filling out the
bugzilla form and allowing it to be edited later would be useful.

To be clear: I'm suggesting the bugzilla entry be an *optional* part of the
Android app. I suspect that if we automatically uploaded every oops,
maintainers would shortly make a mail filter to ignore the reports from
bugzilla.

Sarah Sharp

[-- Attachment #2: Type: text/html, Size: 3981 bytes --]

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

[Masami Hiramatsu]

(2014/05/12 1:29), Levente Kurusa wrote:
> Hi,
> 
> 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 <jason@lakedaemon.net> 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. :-)

I guess we might need a smartphone application for sending oops
to correct server. So, I'd like to suggest following; at step 0,
user downloads oops-report application and he/she might sign-up the
server with his mail via the application(optional). And at step2,
run the app to scan the QR code. The app decodes it and reports to
server via user's account (anonymous is ok). :)
Thus, they don't need to fill the additional forms.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com

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

[H. Peter Anvin]

As valuable as I obviously believe this project is, is there actually
anything that warrants discussion at the Kernel Summit?  It seems like
something to Just Do[TM].

	-hpa

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

[Josh Triplett]

On Sun, May 11, 2014 at 07:38:14PM -0700, H. Peter Anvin wrote:
> As valuable as I obviously believe this project is, is there actually
> anything that warrants discussion at the Kernel Summit?  It seems like
> something to Just Do[TM].

I believe there is actually a key part of this discussion to have at
Kernel Summit.  We don't need to discuss the technical details of the
implementation; we do need to discuss the implications of enabling mass
oops-reporting, the infrastructure and information we want to include in
codes valid for the next decade or so, the tradeoffs between ease of
reporting and value of the reports, some potential approaches to
aggregate the date, and similar.

- Josh Triplett

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

[David Woodhouse]

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

On Sun, 2014-05-11 at 23:13 -0700, Josh Triplett wrote:
> On Sun, May 11, 2014 at 07:38:14PM -0700, H. Peter Anvin wrote:
> > As valuable as I obviously believe this project is, is there actually
> > anything that warrants discussion at the Kernel Summit?  It seems like
> > something to Just Do[TM].
> 
> I believe there is actually a key part of this discussion to have at
> Kernel Summit.  We don't need to discuss the technical details of the
> implementation; we do need to discuss the implications of enabling mass
> oops-reporting, the infrastructure and information we want to include in
> codes valid for the next decade or so, the tradeoffs between ease of
> reporting and value of the reports, some potential approaches to
> aggregate the date, and similar.

In particular, can we avoid the silly trap of the ---[cut here]--- which
comes between a kernel oops, and the potentially useful messages that
were printed right before it.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

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

[Lukáš Czerner]

On Mon, 12 May 2014, David Woodhouse wrote:

> Date: Mon, 12 May 2014 10:23:05 +0100
> From: David Woodhouse <dwmw2@infradead.org>
> To: Josh Triplett <josh@joshtriplett.org>
> Cc: PJ Waskiewicz <pjwaskiewicz@gmail.com>,
>     Jason Cooper <jason@lakedaemon.net>,
>     ksummit-discuss@lists.linuxfoundation.org,
>     Anton Arapov <arapov@gmail.com>, Sarah A Sharp <sarah@minilop.net>,
>     Dirk Hohndel <hohndel@infradead.org>
> Subject: Re: [Ksummit-discuss] [TECH TOPIC] QR encoded oops for the kernel
> 
> On Sun, 2014-05-11 at 23:13 -0700, Josh Triplett wrote:
> > On Sun, May 11, 2014 at 07:38:14PM -0700, H. Peter Anvin wrote:
> > > As valuable as I obviously believe this project is, is there actually
> > > anything that warrants discussion at the Kernel Summit?  It seems like
> > > something to Just Do[TM].
> > 
> > I believe there is actually a key part of this discussion to have at
> > Kernel Summit.  We don't need to discuss the technical details of the
> > implementation; we do need to discuss the implications of enabling mass
> > oops-reporting, the infrastructure and information we want to include in
> > codes valid for the next decade or so, the tradeoffs between ease of
> > reporting and value of the reports, some potential approaches to
> > aggregate the date, and similar.
> 
> In particular, can we avoid the silly trap of the ---[cut here]--- which
> comes between a kernel oops, and the potentially useful messages that
> were printed right before it.

I'd like people to include the lines before the oops as well, it's
often quite useful. The question is how to communicate this
information to the users through the kernel oops ? Also how to
communicate that we usually need the first oops ? Maybe instead of
"cut here" line we can have the one or two sentences about this ?

-Lukas

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

[Jason Cooper]

On Mon, May 12, 2014 at 03:48:32PM +0200, Lukáš Czerner wrote:
> On Mon, 12 May 2014, David Woodhouse wrote:
> 
> > Date: Mon, 12 May 2014 10:23:05 +0100
> > From: David Woodhouse <dwmw2@infradead.org>
> > To: Josh Triplett <josh@joshtriplett.org>
> > Cc: PJ Waskiewicz <pjwaskiewicz@gmail.com>,
> >     Jason Cooper <jason@lakedaemon.net>,
> >     ksummit-discuss@lists.linuxfoundation.org,
> >     Anton Arapov <arapov@gmail.com>, Sarah A Sharp <sarah@minilop.net>,
> >     Dirk Hohndel <hohndel@infradead.org>
> > Subject: Re: [Ksummit-discuss] [TECH TOPIC] QR encoded oops for the kernel
> > 
> > On Sun, 2014-05-11 at 23:13 -0700, Josh Triplett wrote:
> > > On Sun, May 11, 2014 at 07:38:14PM -0700, H. Peter Anvin wrote:
> > > > As valuable as I obviously believe this project is, is there actually
> > > > anything that warrants discussion at the Kernel Summit?  It seems like
> > > > something to Just Do[TM].
> > > 
> > > I believe there is actually a key part of this discussion to have at
> > > Kernel Summit.  We don't need to discuss the technical details of the
> > > implementation; we do need to discuss the implications of enabling mass
> > > oops-reporting, the infrastructure and information we want to include in
> > > codes valid for the next decade or so, the tradeoffs between ease of
> > > reporting and value of the reports, some potential approaches to
> > > aggregate the date, and similar.
> > 
> > In particular, can we avoid the silly trap of the ---[cut here]--- which
> > comes between a kernel oops, and the potentially useful messages that
> > were printed right before it.
> 
> Also how to communicate that we usually need the first oops ?

Well, the QR code can only hold one oops anyway.  Printing the code for
the first should be pretty simple to implement.

thx,

Jason.

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

[H. Peter Anvin]

On 05/12/2014 09:24 AM, Jason Cooper wrote:
> 
> Well, the QR code can only hold one oops anyway.  Printing the code for
> the first should be pretty simple to implement.
> 

A QR code can hold a certain amount of data, which may or may not be
more than one Oops and/or kernel log messages before it.  Compressing
the data would allow for more information, although it involves more
code running on a dodgy kernel.

	-hpa

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

[Jason Cooper]

On Mon, May 12, 2014 at 10:23:05AM +0100, David Woodhouse wrote:
> On Sun, 2014-05-11 at 23:13 -0700, Josh Triplett wrote:
> > On Sun, May 11, 2014 at 07:38:14PM -0700, H. Peter Anvin wrote:
> > > As valuable as I obviously believe this project is, is there actually
> > > anything that warrants discussion at the Kernel Summit?  It seems like
> > > something to Just Do[TM].
> > 
> > I believe there is actually a key part of this discussion to have at
> > Kernel Summit.  We don't need to discuss the technical details of the
> > implementation; we do need to discuss the implications of enabling mass
> > oops-reporting, the infrastructure and information we want to include in
> > codes valid for the next decade or so, the tradeoffs between ease of
> > reporting and value of the reports, some potential approaches to
> > aggregate the date, and similar.
> 
> In particular, can we avoid the silly trap of the ---[cut here]--- which
> comes between a kernel oops, and the potentially useful messages that
> were printed right before it.

Something like this?

thx,

Jason.

------------>8-----------------
diff --git a/kernel/panic.c b/kernel/panic.c
index d02fa9fef46a..797251d87c60 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -407,7 +407,7 @@ static void warn_slowpath_common(const char *file, int line, void *caller,
 {
 	disable_trace_on_warning();
 
-	pr_warn("------------[ cut here ]------------\n");
+	pr_warn("------------[ cut 10 lines above here ]------------\n");
 	pr_warn("WARNING: CPU: %d PID: %d at %s:%d %pS()\n",
 		raw_smp_processor_id(), current->pid, file, line, caller);
 
diff --git a/lib/bug.c b/lib/bug.c
index 168603477f02..ece8c759d454 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -153,7 +153,7 @@ enum bug_trap_type report_bug(unsigned long bugaddr, struct pt_regs *regs)
 
 	if (warning) {
 		/* this is a WARN_ON rather than BUG/BUG_ON */
-		printk(KERN_WARNING "------------[ cut here ]------------\n");
+		printk(KERN_WARNING "------------[ cut 10 lines above here ]------------\n");
 
 		if (file)
 			printk(KERN_WARNING "WARNING: at %s:%u\n",
@@ -171,7 +171,7 @@ enum bug_trap_type report_bug(unsigned long bugaddr, struct pt_regs *regs)
 		return BUG_TRAP_TYPE_WARN;
 	}
 
-	printk(KERN_DEFAULT "------------[ cut here ]------------\n");
+	printk(KERN_DEFAULT "------------[ cut 10 lines above here ]------------\n");
 
 	if (file)
 		printk(KERN_CRIT "kernel BUG at %s:%u!\n",

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

[H. Peter Anvin]

On 05/12/2014 09:22 AM, Jason Cooper wrote:
> 
> Something like this?
> 
>  
> -	pr_warn("------------[ cut here ]------------\n");
> +	pr_warn("------------[ cut 10 lines above here ]------------\n");
>  	pr_warn("WARNING: CPU: %d PID: %d at %s:%d %pS()\n",
>  		raw_smp_processor_id(), current->pid, file, line, caller);
>  

Why not just drop it?

	-hpa

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

[Jason Cooper]

On Mon, May 12, 2014 at 09:46:48AM -0700, H. Peter Anvin wrote:
> On 05/12/2014 09:22 AM, Jason Cooper wrote:
> > 
> > Something like this?
> > 
> >  
> > -	pr_warn("------------[ cut here ]------------\n");
> > +	pr_warn("------------[ cut 10 lines above here ]------------\n");
> >  	pr_warn("WARNING: CPU: %d PID: %d at %s:%d %pS()\n",
> >  		raw_smp_processor_id(), current->pid, file, line, caller);
> >  
> 
> Why not just drop it?

I think there's value in being specific.  First time reporters tend to
quote too little when left to their own devices.  When I was more active
in the Gentoo community, I recall many times getting only the
"make[1]:..." lines or the "emerge" bits.  By the time you ask for more,
the data was lost.

thx,

Jason.

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

[Sarah A Sharp]

On Mon, May 12, 2014 at 10:32 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Mon, May 12, 2014 at 09:46:48AM -0700, H. Peter Anvin wrote:
>> On 05/12/2014 09:22 AM, Jason Cooper wrote:
>> >
>> > Something like this?
>> >
>> >
>> > -   pr_warn("------------[ cut here ]------------\n");
>> > +   pr_warn("------------[ cut 10 lines above here ]------------\n");
>> >     pr_warn("WARNING: CPU: %d PID: %d at %s:%d %pS()\n",
>> >             raw_smp_processor_id(), current->pid, file, line, caller);
>> >
>>
>> Why not just drop it?
>
> I think there's value in being specific.  First time reporters tend to
> quote too little when left to their own devices.  When I was more active
> in the Gentoo community, I recall many times getting only the
> "make[1]:..." lines or the "emerge" bits.  By the time you ask for more,
> the data was lost.

Wasn't the "cut here" line put in for people to know which chunk of
log to feed to scripts/markup_oops.pl?  Or is it smarter these days?

Sarah Sharp

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

[Jason Cooper]

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 <jason@lakedaemon.net> 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.
> >
> >   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?

New form designed for mobile devices.  Based on current conversations,
I'm thinking a box for the email address, and a check-block for
receiving emails regarding the oops/bug.  Nothing more.  Well, maybe a
page title and a simple stat, "You're the XX person to report this oops"

An auto-generated email would contain a 'beginner' link, and a link to
the normal bugzilla login/form for those comfortable with that.

> It would be great if we could allow users to open a new
> bugzilla.kernel.org entry for the oops.

While I agree with the value of a bugzilla entry, I think we need to
keep in mind that we would be opening up oops reporting to a new class
of users.  iow, non-technical folks.

The workflow of an oops reporting should bear that in mind, as well as
any user interfaces along the way.

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

The app is a nice option, but I'd like to keep it optional.  To me, the
first and foremost goal is to get the oops recorded on a kernel.org
system.  Dupes and all.  Anything that raises the barrier for
accomplishing that goal must be carefully considered and justified.

There's value in seeing the same oops has >100 reports, while another
oops has but one.  Once we have that raw data, what we do with it is the
topic worth discussing at KS.

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

My mistake, I thought they were working together.  Of course Teodora
would have the lead.

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

Ack.

thx,

Jason.