Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown <broonie@kernel.org>]

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

On Tue, Apr 18, 2017 at 11:39:22PM +0200, Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 10:56 PM, Linus Torvalds

> > Side note: people should think about various infrastructure/testing
> > people too  So kernel.org, but also things like zero-day etc test
> > labs.

For kernelci.org the kernel people involved are Kevin Hilman and myself,
mainly Kevin.  

There's also some work on automation of actual test running going on in
Linaro intended to end up fulfiling a similar role to the various
build/boot bots which should be in a state to talk about usefully by
October but I don't want to overpromise.  I'll definitely be able to
talk about some of the experience with getting things up and running by
then.

> Hm, we're trying to build up a much more ambitious CI here for drm and
> intel specifically, but nothing all that interesting yet relevant
> beyond drm. What could be interesting (but not for the discussion
> session, more for the general track) is getting our userspace CI team
> to explain what they do. Except that it runs in userspace the gl

I'm wondering if we should be trying to ge a miniconf together for this
stuff, there's a reasonable number of people attacking kernel QA from
various angles and there's probably a lot to be gained from sharing
ideas and experiences.

> A hw testing bof thing for different (driver) subsystems to compare
> notes might be good, but I'm not sure that'd be useful for the group
> discussions really. Probably more talking to the audience than what
> you're aiming for.

I think there's a useful conversation to be had there if we do have a
good selection of downstream users in the room, not just about hardware
testing but more generally about what we're doing upstream around test
and how that's translating to our downstreams.  How do we make sure that
people who are either downstream users or just interested in general
kernel testing find out about tests we're using upstream, how to use
them and so on?  Are the tests we're using useful for them as well as
the developers?

Ideally testing could be another way to open up interaction with people
who haven't been working upstream so much, or if nothing else help
raise the quality of out of tree code, but at the minute it seems like
we have a discoverability problem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]