From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2339EC10F27 for ; Tue, 10 Mar 2020 13:13:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BF465208E4 for ; Tue, 10 Mar 2020 13:13:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF465208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3DA366B0005; Tue, 10 Mar 2020 09:13:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33C8C6B0006; Tue, 10 Mar 2020 09:13:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 204F96B0007; Tue, 10 Mar 2020 09:13:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id 069056B0005 for ; Tue, 10 Mar 2020 09:13:44 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 05126181AEF07 for ; Tue, 10 Mar 2020 13:13:44 +0000 (UTC) X-FDA: 76579494768.26.cause85_373bb30c090e X-HE-Tag: cause85_373bb30c090e X-Filterd-Recvd-Size: 5929 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Mar 2020 13:13:43 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id v9so15784806wrf.10 for ; Tue, 10 Mar 2020 06:13:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Oa5g113veU2Vu4AlqhwVidAaDnTAra7gNy7bFO70rZc=; b=aDsHTKhOhVJy/79u9eI/EXJQrdmK27jG++39ZVzvyXV7+5Ep4fk0pKYuUujnAYuHcN Oa0VzXcLG5Y5HyV5sXdCb5Rmgz7M7Lluft/IWpTKtf33NQIWIOm2cX4717A5VaOJ3p+e 9Mt8TRlo5hKqQvO5Zd7BO1HJ/cLq6Ln0ZA4UORu/XMV9/CWPCeKw/uKZGignaIoq+dEq Y+NrmTK76m3p1wz0ghPdLfbK66aSKt58LnNFCWNbaAa0x53op/x8tcyJfkgan3Vuh8yn QX89YUL4Ek+u3VDQmxZGmMRnhECCSWShRt72IDqPGjBotUEkFEYxX7gMqq7FkCFCKqGp tXEQ== X-Gm-Message-State: ANhLgQ1wUY+EfYSUtJ7BOz8e+YDoz4YMCl5pVkYnyjbLs0jcyO/0LRoy vUQ2ctKteZk2RPANt3BEpjc= X-Google-Smtp-Source: ADFU+vuoqLKuNCFV1S8JMIVLIpzM6ZHX7oSMYDAvFAe+RDvvRUTcPFeCW1aEmNfzgKcgFP+a7BaerA== X-Received: by 2002:a5d:4685:: with SMTP id u5mr26336545wrq.69.1583846022170; Tue, 10 Mar 2020 06:13:42 -0700 (PDT) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id l83sm4132454wmf.43.2020.03.10.06.13.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2020 06:13:41 -0700 (PDT) Date: Tue, 10 Mar 2020 14:13:39 +0100 From: Michal Hocko 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: <20200310131339.GJ8447@dhcp22.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000535, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 -- Michal Hocko SUSE Labs