Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6894654ybf; Fri, 6 Mar 2020 06:36:04 -0800 (PST) X-Google-Smtp-Source: ADFU+vvSGyOKPlNKDcrFBLhj99TMc4Ia4EgGC0l7UzP+I+R8blH+7Qwhuz4kK+HB4YddMqt0igGU X-Received: by 2002:a05:6830:210f:: with SMTP id i15mr2711230otc.335.1583505364018; Fri, 06 Mar 2020 06:36:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583505364; cv=none; d=google.com; s=arc-20160816; b=sGA5sz+nwOiJJPW5GcYoEZjoT46WXO3lQvBT+BZiTwS42LfoQ10Tj8+dAMqcJrCdsg I8OChJQzAtMtWVn7PnxhXVSCe3gmEEukO/5XMwFSxRf0JVIGHKAaebjyWmS3TzaLIDLu 0Gdj3BkycOPjMT54UaAI+wGcGund3ZJzMhnhDb538R3wE9O7l6leGvJxjjGwxnlVrMk/ IEpbOWR59fscOLRdtog2ygFsD9tgGQjl04QetsNbHxbCa5qBeppqlnjnSnXxEO4PZHSL jpCDenxCU+8P/XzkCxzXGzq+mONHqdi1o3iJMid0AuYB8+PRolbOopAfDYVkPkb7b6BH 9fiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:mime-version:user-agent:date:message-id:subject :from:to:dkim-signature; bh=gPp/JOqSfFor2drm+SXytCIq/9gBWBTnvgG0JC6dgNM=; b=q9XJK1X/S5t1Pcn2diVZf93pLcOpf3hL8UNFwTx9K+aQ7I+6QJbuCdMY/xd3eFjplc J6bA5ZTS0DCXtywpNmuEc1mgtkx7Dh4WyPEB8z9H7ErpKTkatkFBRB+Or5SqlOmZYwxv N5kh4eTS93UMZdvvsJWSiYBIvoWz/t+Zqh3SysOmXJ1Ai8ZFtS/FbMcUdCKzmYy+6oE0 EsagIk+NxhGqFAUHbyfqrAOeXF6h/8i4j0fvCuKpcccA7PEpDMXUHx+BvkUq9A6QMfC+ e3kh7IuC1huYKGPFQnwSv9WM6tm2AjNOLxPQf48/dOlzQUhqIdWXOi9O4mmmKN4jW2Ue WMqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=R6D2fwgY; 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 d4si1420377otp.214.2020.03.06.06.35.46; Fri, 06 Mar 2020 06:36:03 -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; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=R6D2fwgY; 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 S1726090AbgCFOfp (ORCPT + 99 others); Fri, 6 Mar 2020 09:35:45 -0500 Received: from mail-qv1-f47.google.com ([209.85.219.47]:44405 "EHLO mail-qv1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726108AbgCFOfo (ORCPT ); Fri, 6 Mar 2020 09:35:44 -0500 Received: by mail-qv1-f47.google.com with SMTP id bt20so645475qvb.11 for ; Fri, 06 Mar 2020 06:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=gPp/JOqSfFor2drm+SXytCIq/9gBWBTnvgG0JC6dgNM=; b=R6D2fwgYCDJTLwCQ+Pv/dbaRa7A1QbxEYJ0FaGXrlUmQ0jE3K8WZZQ2+tGjrrmujzN SSy0cbS/K5s9EbOvpYY+tuPSmNKsFKDYdL8jbgzxQBRWZBn3RRdpJ3kk4tvVlY6DOULE nSB8pwI3jeTb7Phe1gUrVCG07Og1a7xsaUh9QuBhysVmGyRIMS96HDDBGSZCzj+mvEbo qmh4WOhUeYUk5TMdC65+a7f5f8E+cbZOz5jaqlYJlZNJ71vMRGi5htZWUPvn0Zsm91Yx MjFCxBtQ8deY5Y+57kwuvxdhumqCEff45QD4a7zc9VKE2UShFJXV1+ADY/u8mzaRYGKd 8UWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=gPp/JOqSfFor2drm+SXytCIq/9gBWBTnvgG0JC6dgNM=; b=Hi9l71f2U+ts9TkVAqXCAzCf7DpIZDlMTf/ieNXojaRLu30TRj8cbsquOMasg/8jZ7 2pxlYVRB/uxs/EFIBAdJbd3sRyXMONt3LTB3xHIn50tQClh24tBof9T3Os+GdzyUbf6/ EWm7uxPn+Yh33A9KY8o8ev/tH65iJCQiHVCURjftjJ0fg0DrfIa4/P5w/JiUQIt2gTpQ dPGaBeOGGFhO/2YSFkBVXZITUYYJC/GP/8NliqW5hLMnnqaAvUp2Ql00UJl4Zr5dQpeT 0yrChYtwRL/CdLBojOX9IT0J+KEHmItEtSrFBLAlGl0bK3rqimEbUab+0LzoNy7Wu0lC 2YOQ== X-Gm-Message-State: ANhLgQ12uuwpVq2awHo92dRlq6ymvqYItQuU3ygJrRigWzGGEAhDlc1/ zPGJmm4Ojw5/iIz1mCUpEQnuNA== X-Received: by 2002:ad4:41cf:: with SMTP id a15mr3142478qvq.125.1583505343378; Fri, 06 Mar 2020 06:35:43 -0800 (PST) Received: from [192.168.1.106] ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id i1sm12426803qtg.31.2020.03.06.06.35.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Mar 2020 06:35:42 -0800 (PST) To: 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 From: Josef Bacik Subject: [LSFMMBPF TOPIC] Killing LSFMMBPF Message-ID: Date: Fri, 6 Mar 2020 09:35:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hello, This has been a topic that I've been thinking about a lot recently, mostly because of the giant amount of work that has been organizing LSFMMBPF. I was going to wait until afterwards to bring it up, hoping that maybe it was just me being done with the whole process and that time would give me a different perspective, but recent discussions has made it clear I'm not the only one. LSFMMBPF is not useful to me personally, and not an optimal use of the communities time. The things that we want to get out of LSFMMBPF are (generally) 1) Reach consensus on any multi-subsystem contentious changes that have come up over the past year. 2) Inform our fellow developers of new things that we are working on that we would like help with, or need to think about for the upcoming year. 3) "Hallway track". We are after all a community, and I for one like spending time with developers that I don't get to interact with on a daily basis. 4) Provide a way to help integrate new developers into the community with face time. It is far easier to work with people once you can put a face to a name, and this is especially valuable for new developers. These are all really good goals, and why we love the idea of LSFMMBPF. But having attended these things every year for the last 13 years, it has become less and less of these things, at least from my perspective. A few problems (as I see them) are 1) The invitation process. We've tried many different things, and I think we generally do a good job here, but the fact is if I don't know somebody I'm not going to give them a very high rating, making it difficult to actually bring in new people. 2) There are so many of us. Especially with the addition of the BPF crowd we are now larger than ever. This makes problem #1 even more apparent, even if I weighted some of the new people higher who's slot should they take instead? I have 0 problems finding 20 people in the FS community who should absolutely be in the room. But now I'm trying to squeeze in 1-5 extra people. Propagate that across all the tracks and now we're at an extra 20ish people. 3) Half the people I want to talk to aren't even in the room. This may be a uniquely file system track problem, but most of my work is in btrfs, and I want to talk to my fellow btrfs developers. But again, we're trying to invite an entire community, so many of them simply don't request invitations, or just don't get invited. 3) Sponsorships. This is still the best way to get to all of the core developers, so we're getting more and more sponsors in order to buy their slots to get access to people. This is working as intended, and I'm not putting down our awesome sponsors, but this again adds to the amount of people that are showing up at what is supposed to be a working conference. 4) Presentations. 90% of the conference is 1-2 people standing at the front of the room, talking to a room of 20-100 people, with only a few people in the audience who cares. We do our best to curate the presentations so we're not wasting peoples time, but in the end I don't care what David Howells is doing with mount, I trust him to do the right thing and he really just needs to trap Viro in a room to work it out, he doesn't need all of us. 5) Actually planning this thing. I have been on the PC for at least the last 5 years, and this year I'm running the whole thing. We specifically laid out plans to rotate in new blood so this sort of thing stopped happening, and this year we've done a good job of that. However it is a giant amount of work for anybody involved, especially for the whole conference chair. Add in something like COVID-19 to the mix and now I just want to burn the whole thing to the ground. Planning this thing is not free, it does require work and effort. So what do I propose? I propose we kill LSFMMBPF. Many people have suggested this elsewhere, but I think we really need to seriously consider it. Most of us all go to the Linux Plumbers conference. We could accomplish our main goals with Plumbers without having to deal with all of the above problems. 1) The invitation process. This goes away. The people/companies that want to discuss things with the rest of us can all get to plumbers the normal way. We get new blood that we may miss through the invitation process because they can simply register for Plumbers on their own. 2) Presentations. We can have track miniconfs where we still curate talks, but there could be much less of them and we could just use the time to do what LSFMMBPF was meant to do, put us all in a room so we can hack on things together. 3) BOFs. Now all of the xfs/btrfs/ext4 guys can show up, because again they don't have to worry about some invitation process, and now real meetings can happen between people that really want to talk to each other face to face. 4) Planning becomes much simpler. I've organized miniconf's at plumbers before, it is far simpler than LSFMMBPF. You only have to worry about one thing, is this presentation useful. I no longer have to worry about am I inviting the right people, do we have enough money to cover the space. Is there enough space for everybody? Etc. I think this is worth a discussion at the very least. Maybe killing LSFMMBPF is too drastic, maybe there are some other ideas that would address the same problems. I'd love to hear the whole communities thoughts on this, because after all this is supposed to be a community event, and we should all be heard. Thanks,