From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 793C3483 for ; Wed, 24 Aug 2016 14:44:50 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 34595174 for ; Wed, 24 Aug 2016 14:44:49 +0000 (UTC) Date: Wed, 24 Aug 2016 10:44:41 -0400 From: Josh Triplett To: Daniel Vetter Message-ID: <20160824144441.xwzr65aepyqggces@x> References: <20160824130832.GA28564@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [CORE TOPIC] GPL defense issues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Aug 24, 2016 at 04:38:47PM +0200, Daniel Vetter wrote: > On Wed, Aug 24, 2016 at 3:08 PM, Greg KH wrote: > > Anyway, we try to stick to technical topics from the developers of the > > kernel for the kernel summit wherever possible, and I think that the > > deadline for proposing new topics has passed, so I don't think there's > > much that can be done this late in the process. > > Hm, I always thought the point of KS is to talk about process, > painpoints in the same and other topics of larger scale. Personally I > think Karen's topic fits into this, and I think it would be > interesting (at least for me). The pure technical topics are > interesting to keep up on general things, but lwn.net does a great job > at covering these wherever they happen - no reason for me to fly > around the globe for those. At least that's been my experience with > the past few KS, I've always took home a lot more from the > process/more general sessions than the latest deep technical topic. > Might just be that gfx folks are somewhat in a world of their own. It's not just you. Kernel Summit exists to cover things that a mailing list discussion just won't work for. We can handle the vast majority of technical issues with asynchronous, distributed discussions, to the point that Kernel Summit regularly rejects some technical topics either because they don't actually need an in-person discussion or because someone just needs to go write a patch or make an RFC proposal. Process issues, on the other hand, go much more smoothly if you get the right people in the room, quickly bounce around a few concrete possibilities, and make a call for what path to start down (even if that changes later).