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;
Date:   Tue, 10 Mar 2020 14:13:39 +0100
From:   Michal Hocko <mhocko@kernel.org>
To:     Josef Bacik <josef@toxicpanda.com>
Cc:     lsf-pc <lsf-pc@lists.linuxfoundation.org>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        linux-mm@kvack.org, linux-xfs@vger.kernel.org,
        Btrfs BTRFS <linux-btrfs@vger.kernel.org>, 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: <b506a373-c127-b92e-9824-16e8267fc910@toxicpanda.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b506a373-c127-b92e-9824-16e8267fc910@toxicpanda.com>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

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