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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 48EB5C10DCE for ; Fri, 6 Mar 2020 15:56:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 12FC42072A for ; Fri, 6 Mar 2020 15:56:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12FC42072A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9B80C6B0006; Fri, 6 Mar 2020 10:56:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 968836B0007; Fri, 6 Mar 2020 10:56:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87F9B6B0008; Fri, 6 Mar 2020 10:56:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0172.hostedemail.com [216.40.44.172]) by kanga.kvack.org (Postfix) with ESMTP id 7181F6B0006 for ; Fri, 6 Mar 2020 10:56:14 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2A0168248047 for ; Fri, 6 Mar 2020 15:56:14 +0000 (UTC) X-FDA: 76565389068.17.can26_1945ee1bcc454 X-HE-Tag: can26_1945ee1bcc454 X-Filterd-Recvd-Size: 3723 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Fri, 6 Mar 2020 15:56:13 +0000 (UTC) Received: from callcc.thunk.org (pool-72-93-95-157.bstnma.fios.verizon.net [72.93.95.157]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 026FuBGe022773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Mar 2020 10:56:12 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 8B97642045B; Fri, 6 Mar 2020 10:56:11 -0500 (EST) Date: Fri, 6 Mar 2020 10:56:11 -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: <20200306155611.GA167883@mit.edu> 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.001187, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Mar 06, 2020 at 09:35:41AM -0500, Josef Bacik wrote: > 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..... I suggest that we try to decouple the question of should we have LSF/MM/BPF in 2020 and COVID-19, with the question of what should LSF/MM/BPF (perhaps in some transfigured form) should look like in 2021 and in the future. A lot of the the concerns expressed in this e-mails are ones that I have been concerned about, especially: > 2) There are so many of us.... > 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.... > 4) Presentations.... These *exactly* mirror the dynamic that we saw with the Kernel Summit, and how we've migrated to a the Maintainer's Summit with a Kernel centric track which is currently colocated with Plumbers. I think it is still useful to have something where we reach consensus on multi-subsystem contentious changes. But I think those topics could probably fit within a day or maybe a half day. Does that sound familiar? That's essentially what we now have with the Maintainer'st Summit. The problem with Plumbers is that it's really, really full. Not having invitations doesn't magically go away; Plumbers last year had to deal with long waitlist, and strugglinig to make sure that all of the critical people who need be present so that the various Miniconfs could be successful. This is why I've been pushing so hard for a second Linux systems focused event in the first half of the year. I think if we colocate the set of topics which are currently in LSF/MM, the more file system specific presentations, the ext4/xfs/btrfs mini-summits/working sessions, and the maintainer's summit / kernel summit, we would have critical mass. And I am sure there will be *plenty* of topics left over for Plumbers. Cheers, - Ted