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 23C79C10DCE for ; Fri, 6 Mar 2020 18:48:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EF87420714 for ; Fri, 6 Mar 2020 18:48:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726185AbgCFSsG (ORCPT ); Fri, 6 Mar 2020 13:48:06 -0500 Received: from shelob.surriel.com ([96.67.55.147]:42750 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725922AbgCFSsG (ORCPT ); Fri, 6 Mar 2020 13:48:06 -0500 X-Greylist: delayed 1057 seconds by postgrey-1.27 at vger.kernel.org; Fri, 06 Mar 2020 13:48:05 EST Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jAHjr-0005Z9-Kq; Fri, 06 Mar 2020 13:30:23 -0500 Message-ID: <96a0ba8151d76d14f1753ef25740fd02e6622bde.camel@surriel.com> Subject: Re: [LSFMMBPF TOPIC] Killing LSFMMBPF From: Rik van Riel To: "Theodore Y. Ts'o" , 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 Date: Fri, 06 Mar 2020 13:30:23 -0500 In-Reply-To: <20200306155611.GA167883@mit.edu> References: <20200306155611.GA167883@mit.edu> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-w/qZdMTI+1T3jriBWjjb" User-Agent: Evolution 3.34.3 (3.34.3-1.fc31) MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org --=-w/qZdMTI+1T3jriBWjjb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2020-03-06 at 10:56 -0500, Theodore Y. Ts'o wrote: > 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. >=20 > 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. That sounds like a good idea to me, as well. Instead of trying to invite "all the useful people" on a few fixed topics, which LSF/MM did very well, but which the Linux community has long outgrown, resulting in us being unable to invite some very good people, we can turn things on its head a little organization wise. We can host a number of (half day?) mini conferences on various Linux kernel topics, maybe still with some focus around LSF/MM/IO, and have a small number of general track discussion sessions. Once the topics of the mini conferences have been chosen, people can figure out whether or not they want to attend that year. This could help us avoid the "oops, we couldn't invite two of the people who really should have been here for this=20 discussion" issue that has been difficult to avoid with=20 LSF/MM having more interest, and more topics, than available slots for people to attend. TL;DR: decide on topics, not invitees. --=20 All Rights Reversed. --=-w/qZdMTI+1T3jriBWjjb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAl5ilr8ACgkQznnekoTE 3oMNGwgAvmBDEG2kfhjeMZ9/J7JXRyU/bnp9OdUm/NqLqP67Wv3imUaf7sA8FF1+ 6q0fOaiCUu458Ec+6zYB1PH4Kb+p1epyLc0cS6xA2lym+RoKE2wqHt0XazUyw4SU UanK1Hln0IQarvMgeW+iZBJesqmqlH/hBGFrp3HG1IHfIRpTCLnTRmVIrn6x0XGr cNVNQceVQRHAzJ/3CJAcjYedhbylLuWFOc49CGjrWVz5Q390UAyyLgr2QZVerhCO Fbqi5QmLuahR22KyHFrPCUrh8X/JpUloulRBhAsnr71xugzB29A/kS+pjb9vWzk3 1EpVZ6mHCBb5t70F/rQdiQybxuFeaw== =f4H4 -----END PGP SIGNATURE----- --=-w/qZdMTI+1T3jriBWjjb--