bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Date: Tue, 10 Mar 2020 14:13:39 +0100	[thread overview]
Message-ID: <20200310131339.GJ8447@dhcp22.suse.cz> (raw)
In-Reply-To: <b506a373-c127-b92e-9824-16e8267fc910@toxicpanda.com>

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

  parent reply	other threads:[~2020-03-10 13:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-06 14:35 [LSFMMBPF TOPIC] Killing LSFMMBPF Josef Bacik
2020-03-06 15:29 ` Jason Gunthorpe
2020-03-06 15:30 ` [Lsf-pc] " Amir Goldstein
2020-03-06 15:55 ` Josef Bacik
2020-03-06 15:56 ` Theodore Y. Ts'o
2020-03-06 16:08   ` Josef Bacik
2020-03-06 19:48     ` Theodore Y. Ts'o
2020-03-06 18:30   ` Rik van Riel
2020-03-07 18:54   ` [LSFMMBPF TOPIC] LSFMMBPF 2020 COVID-19 status update Luis Chamberlain
2020-03-07 19:00     ` Josef Bacik
2020-03-07 19:12     ` James Bottomley
2020-03-06 16:04 ` [LSFMMBPF TOPIC] Killing LSFMMBPF Nikolay Borisov
2020-03-06 16:05 ` Matthew Wilcox
2020-03-06 17:04   ` Al Viro
2020-03-06 17:37   ` James Bottomley
2020-03-06 18:06     ` Jason Gunthorpe
2020-03-06 19:07       ` Martin K. Petersen
2020-03-06 19:15         ` James Bottomley
2020-03-06 19:20           ` Martin K. Petersen
2020-03-06 18:23     ` Matthew Wilcox
2020-03-06 19:25       ` James Bottomley
2020-03-06 16:15 ` James Bottomley
2020-03-06 16:28   ` Christian Brauner
2020-03-06 16:31     ` Josef Bacik
2020-03-06 19:27 ` [LSFMMBPF TOPIC] long live LFSMMBPF Chris Mason
2020-03-06 19:41   ` James Bottomley
2020-03-06 19:56     ` Chris Mason
2020-03-06 20:25     ` Theodore Y. Ts'o
2020-03-07  3:14 ` [LSFMMBPF TOPIC] Killing LSFMMBPF Steve French
2020-03-10 13:13 ` Michal Hocko [this message]
2020-03-10 13:40   ` Josef Bacik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200310131339.GJ8447@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lsf-pc@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).