Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp701054ybh; Tue, 10 Mar 2020 06:43:41 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuZWS/wKer1jQp/R+QXJM9pYrK0X7nJ1JIH1ijdu5Wu/byUCEUEQneOYJSlHgc63QtcXwvQ X-Received: by 2002:a9d:7e8b:: with SMTP id m11mr17251013otp.83.1583847821829; Tue, 10 Mar 2020 06:43:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583847821; cv=none; d=google.com; s=arc-20160816; b=STvFC3PpsqgLle1J76OstdqDbLhNDyxFQW5X9SLKjGpYfW/bAfxeGI4w5GD7mGVzN/ D5zzPzJdik1SQKPSdx16u8MZc+Fr+yXFCsA417e2qGHcZPg5Vq3YHQ/iJVsycGNw8mpD xPJxi4BtYpyW2gNvlRB7gyDgZPyWIxhWrF/vPWn6HbxdkqbhREPzhdfB1OW9PeszfFtY WAEB8ndo5dbevjtA2kqtSypSCdMtno2zDlLVxgZaw2G3Ag2dfPk2GoSRJPxRszLrkzNl 4+NQWQYhFDylhcj8G2gY1is+sraTovYc/VphFTet5fqvJOD1TExm3yNVvi5WKx5Ek9IK 1fBQ== 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:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=5vu1i6JU9zdD/JCzCOO+f8X/TnDT40+qLiG1pRNeZis=; b=Bh2ldyLM682vfkBGGeQ8um/NnQA/Pbe9TpDmqxyV+OIU85OMjziQcgh7l5ff+wm+iz iAludptrF/M0Md12vtQ/Su51SEbEb5ggaico43MhGayz4uukIq94DESAMz9i+XcmwpJN +GE9Ep/PUPS39dJIAv6UhLAuOPhDsVZOIXEse5KaRtZLkJcnugw+IfCABbbXLCriOU79 5TshBOC6x7PltDJ54JpNysuGBsPPv7QImLUo18tZnjjwhEUOvc6lOUGQUn5OGAN+Y6Qk kcay8EQrMwWTXspGh8i1UauCK1nIiaAYXZwO82Hr3/hUcyqKExF/nIbGcc/1H0WLiHKk jOJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=Iq0NtN8i; 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 d5si3892245otc.161.2020.03.10.06.43.25; Tue, 10 Mar 2020 06:43:41 -0700 (PDT) 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=Iq0NtN8i; 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 S1726680AbgCJNkr (ORCPT + 99 others); Tue, 10 Mar 2020 09:40:47 -0400 Received: from mail-qt1-f177.google.com ([209.85.160.177]:36540 "EHLO mail-qt1-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726514AbgCJNkr (ORCPT ); Tue, 10 Mar 2020 09:40:47 -0400 Received: by mail-qt1-f177.google.com with SMTP id m33so9650996qtb.3 for ; Tue, 10 Mar 2020 06:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5vu1i6JU9zdD/JCzCOO+f8X/TnDT40+qLiG1pRNeZis=; b=Iq0NtN8iD4XI731ngV4spLqbk12fnGylmVITnZ9bxj57mUoRVxK+PwvvLPM/3tAibN gBoInvL2JHteW6v2glnccwOP0mraO0+z90GVHrCGy7WbKgT6IRWLcRpvLhCN8UIFZ3YT +fJKcI1b+B2tANT1L4y58qeoCR906gvWzfhI3HQQd/7LH8fPWPc42pLuLzpGUnlfPvbS r1nWj7/gZKUiN4mNDc/iC6LgZcTuqggj1UpNx0xfrZWiaN97k9FhC/+t6q/06RBDX3in 5gW5xH151Mk+BVxx5QlvJYZaAaVfbk1qPd0l4LURVqryvAMCk85iACLBrHmhf3S8ym83 8ZoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5vu1i6JU9zdD/JCzCOO+f8X/TnDT40+qLiG1pRNeZis=; b=BCEf1KUIqCNPTwym2FVohC47zMNYiul0zJSxJM9VPLQGmCMPp5zuUc2RQ4i5i43Tt/ 1EG01sjPhHeTzhK9vUl0U6Z1i+QIvOQV/1DFsCY6MaUOlay1ov8W36WANEFqTZattArw TwrSwNKoGHtwrn5T2kArqIVcai5uYmrDzHus/x8sot1o9G3PUW6rq9+RQreLPr+1sdNB T0nDJ9MGBWGi/TiUD69xruWMw8wc/ogT3cGVxAyioeK8qprDcaGOdWv6Ja24UGUvfjK8 ilQVbIC3flcyGpnX7DTjB9Cz8u4LT+Eee4118+RL7JcfH6tBRUkMMTnZ2fjZmN3EqwYr u/OQ== X-Gm-Message-State: ANhLgQ3Ql4Wnt/FvmnIBWRJCV5ZD5ytJZBxRRD+2pWgCvq4W5qsCrAf4 mYoYIwV67JB81hur43aldk9Llg== X-Received: by 2002:ac8:6753:: with SMTP id n19mr18773081qtp.193.1583847645476; Tue, 10 Mar 2020 06:40:45 -0700 (PDT) Received: from [192.168.1.106] ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id w132sm1652276qkb.96.2020.03.10.06.40.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2020 06:40:44 -0700 (PDT) Subject: Re: [LSFMMBPF TOPIC] Killing LSFMMBPF To: Michal Hocko 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 References: <20200310131339.GJ8447@dhcp22.suse.cz> From: Josef Bacik Message-ID: <8b09da1d-d170-3857-4478-78afb647b551@toxicpanda.com> Date: Tue, 10 Mar 2020 09:40:43 -0400 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 In-Reply-To: <20200310131339.GJ8447@dhcp22.suse.cz> 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 On 3/10/20 9:13 AM, Michal Hocko wrote: > On Fri 06-03-20 09:35:41, Josef Bacik wrote: >> 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. > > There is undoubtedly a lot of work to make a great conference. I have hard > time imagine this could be ever done without a lot of time and effort on > the organizing side. I do not believe we can simply outsource a highly > technical conference to somebody outside of the community. LF is doing a > lot of great work to help with the venue and related stuff but content > wise it is still on the community IMHO. > > [...] >> 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. > > My experience from the MM track involvement last few years is slightly > different. We have always had a higher demand than seats available > for the track. We have tried really hard to bring people who could > contribute the most requested topic into the room. We have also tried to > bring new contributors in. There are always compromises to be made but > my recollection is that discussions were usually very useful and moved > topics forward. The room size played an important role in that regard. > >> 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. > > Yes, BPF track made the conference larger indeed. This might be problem > for funding but it didn't really cause much more work for tracks > organization (well for MM at least). > >> 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. > > I do not have the same experience on the MM track. Even though the whole > community is hard to fit into the room, there tends to be a sufficient > mass to move a topic forward usually. Even if we cannot conclude many > topics there are usually many action items as an outcome. > > [...] > >> So what do I propose? I propose we kill LSFMMBPF. > > This would be really unfortunate. LSFMMBPF has been the most attractive > conference for me exactly because of the size and cost/benefit. I do > realize we are growing and that should be somehow reflected in the > future. I do not have good answers how to do that yet unfortunately. > Maybe we really need to split the core agenda and topics which could be > discussed/presented on other conferences. Or collocate with another > conference but I have a feeling that we could cover more since LSFMMBPF > LSFMMBPF is still by far the most useful conference I attend, so much so that it's basically the only thing I attend anymore. My point is less about no longer having a conference at all, and more about changing what we currently have to be more useful to more people. For MM, and I assume BPF, it's much different as you guys are all on the same codebase. You get 25 people in the room chances are a much larger percentage of you are interested in each individual topic. File systems and storage? Way less so. We've expanded to 3 days of conference, which has only exacerbated this issue for me. Now I have a full day that I'm trying to fill with interesting topics that we're all interested in, and it's a struggle. If instead we had everybody from the file system community there then I could just say "OK day 3 is BoF day, have your FS specific meetups!" and be done with it. But as it stands I know XFS is missing probably 1/3 of their main contributors, and Btrfs is missing 1/2 to 2/3 of our developers. In order to accomplish that we need to radically change the structure of the conference, hence my hyperbolic suggestion. I think what Ted suggested is probably my ideal solution, we have a kernel focused spring conference where the whole community gets together, and then we have tracks that we carve up. But is it a problem worth solving? I'm not sure. I know how I feel, but maybe I'm the crazy one. I think its worth discussing. If more people like how we currently do it then we can just keep trucking along. It's not like I'll stop showing up, this is still a tremendously useful conference. I just think we can do better. Thanks, Josef