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

[Levente Kurusa <levex@linux.com>]

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