Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp7172985ybf; Fri, 6 Mar 2020 11:49:13 -0800 (PST) X-Google-Smtp-Source: ADFU+vsTcrCTdAuTyGfgE/VrV4hmM/WzbZ4+oY+lq1xMLTzbyInNv4FojvFbEZFhh/nIBCRFEzto X-Received: by 2002:a9d:5e8b:: with SMTP id f11mr3978402otl.110.1583524152940; Fri, 06 Mar 2020 11:49:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583524152; cv=none; d=google.com; s=arc-20160816; b=LolIkm+koKSWS7Iz0fOi/J7uzv0lNGyn/b+NoHykghNZKbRQwz9jkHftsUcBWyYh+K v7wlePtjL30lpHDEBzuLTWrUs3gY40LqHJMrQj+wBAl1zBzVyQijD8Sw7nqFAn907f4W qfaIxCptc7hcoYqTX/LqzITkA4h/IXUr9lbd1eOzHo7/O7/E7csDIpSeBx0PnhwpEDzg NBGlz1vkI04fCv0kfbDnlbGIQYObmLek9fD/15Hb0aiLYcnXH88OVX5HsDXZyv89M8gp aEw6b3/lhvNhDM4FKUcXI/+lFDztAWDGo9akG3kTz2LryCygxjnfNYmfEvQBWJ1XkXah hHvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=U645GyZ2LbZULb5/CcfGPRHmNYcM4dc+afzRMiRYq2Y=; b=JUEPNMXbH51wX6V4l5ETU6Df2eFga2UegTLbzawrTmJUO5IyE+YLFktCbvNWdwGf16 sWScolGLqYNnO3iuGUSBQV08Kuft4NMbsOq3n2iL/uzXjKEcxTIbfYTvgSnYVc+QlsMs FevdBXn0pKghiW6s9RFU/30g79TWDrh3yXwAbNi8NQ0b1eCpWdsbTvc2ViUcFKBJEw1I u0ldIyX2QCTOcAC7dFEQ7v39BFmk/j+8tF7CmVoBxoinB+0wfVT0ub52vV8vO71mHdL4 62uH6sE2gHw63URkJuU9CcVSInhOy16yt7SvN3QfZ0oYnuDBfGNSGFmB/mNma6smz7p2 vLkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l3si180496oig.197.2020.03.06.11.49.01; Fri, 06 Mar 2020 11:49:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726083AbgCFTtA (ORCPT + 99 others); Fri, 6 Mar 2020 14:49:00 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:60746 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725922AbgCFTtA (ORCPT ); Fri, 6 Mar 2020 14:49:00 -0500 Received: from callcc.thunk.org (guestnat-104-133-0-105.corp.google.com [104.133.0.105] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 026JmhG1023168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Mar 2020 14:48:44 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 8CEDB42045B; Fri, 6 Mar 2020 14:48:43 -0500 (EST) Date: Fri, 6 Mar 2020 14:48:43 -0500 From: "Theodore Y. Ts'o" To: Josef Bacik Cc: lsf-pc , Linux FS Devel , linux-mm@kvack.org, linux-xfs@vger.kernel.org, Btrfs BTRFS , bpf@vger.kernel.org, linux-ext4@vger.kernel.org, linux-block@vger.kernel.org Subject: Re: [LSFMMBPF TOPIC] Killing LSFMMBPF Message-ID: <20200306194843.GA12490@mit.edu> References: <20200306155611.GA167883@mit.edu> <72708005-0810-1957-1e58-5b70779ab6db@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72708005-0810-1957-1e58-5b70779ab6db@toxicpanda.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri, Mar 06, 2020 at 11:08:36AM -0500, Josef Bacik wrote: > > I'd be down for this. Would you leave the thing open so anybody can > register, or would you still have an invitation system? I really, really > despise the invitation system just because it's inherently self limiting. > However I do want to make sure we are getting relevant people in the room, > and not making it this "oh shit, I forgot to register, and now the > conference is full" sort of situations. Thanks, There are lots of different ways it can be done. The Maintainer's Summit is an invite-only half-day event. That's mainly because it's about development processes, and there are lots of people who have a strong interest in that, but we want to keep it done to small number of people so we can have real conversations. At Plumbers, the miniconfs leads can give a list of (six?) people they really want to be present. A few get free registration; the others get guaranteed registrations thus bypassing the waitlist. One of the problems is that the miniconf leads don't always get the list of people to the planning committee until late in the process, which made the waitlist management problem even more painful. At the miniconf, there is social pressure so that the key attendees are seated near the front of the room, and there might be audience of a few hundred that are in listen-mostly mode, but for most technical topics, that isn't that much of a problem. I've also seen other cases where the room is small, and there is a list of people who have guaranteed access to the room, and everyone else (up to the fire limit) might have to sit or stand against the wall, etc. If we have a conference with many tracks, the different tracks can have different admittance policies, such is as the case with the Maintainer's Summit, Kernel Summit, Miniconfs, etc. So that's something which I think can be negotiated. I suspect that for most of the LSF/MM contential topics, I doubt we would have hundreds of people clamoring to get in on a discussion about to handle, say, clearing DAX flag on files that might still be in use by some RDMA drive. That is *such* a fascinating topic, but I doubt there really will be a need to limit attendance. :-) - Ted P.S. I do need to note that there is one big advantage to invite-only summts such as the LSF/MM and the old-style Kernel Summit. Companies who really want to present about, say, dual-actuator HDD's, or the latest NVMe / Open Channel interface, are much more likely to pay $$$ to get access to an invite-only event. When we moved to the process-only Maintainer's Summit, and the Kernel Summit for the technical tracks, it most definitely hurt the amount of sponsorship dollars that we got for the Maintainer's Summit. That's not a bad thing, but it might mean that we will need to cut costs by drafting behind the LF, and maybe not having as nice evening receptions, or as nice attendee gifts like we used to do in the early years of the Kernel Summit. Personally, I think that's *fine*; it's the collaboration with fellow developers which is highest on my list of priorities, and not the opportunities for fine dining or going to fun cities. And if giving up on some of these amenities means that I can bring some of the more junior engineers on my team so they can meet other file system developers, I'm **all** for it. But for some folks, they may view this tradeoff as a loss.