Message-ID: <yq1eeu51ev0.fsf@oracle.com>
Date:   Fri, 06 Mar 2020 14:07:47 -0500
From:   "Martin K. Petersen" <martin.petersen@...cle.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     James Bottomley <James.Bottomley@...senPartnership.com>,
        Matthew Wilcox <willy@...radead.org>,
        Josef Bacik <josef@...icpanda.com>,
        lsf-pc <lsf-pc@...ts.linuxfoundation.org>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        linux-mm@...ck.org, linux-xfs@...r.kernel.org,
        Btrfs BTRFS <linux-btrfs@...r.kernel.org>, bpf@...r.kernel.org,
        linux-ext4@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [LSFMMBPF TOPIC] Killing LSFMMBPF


Jason,

> Yes, I can confirm this from another smaller hotel-style conference
> I've been involved organizing on occasion. $600-$800 is required to
> break even without major sponsorship $$ for the ~100 people mark, and
> that is without the usual food and venue perks we see at
> plumbers/lsfmm.

Yep. Our actual per-person cost for LSF/MM/BPF is in excess of $1K. That
limits who we can invite. Personally I absolutely hate the invitation
aspect and process. But we are very constrained wrt. how many we can
actually accommodate by the amount of funding we get. Things appear to
be better this year, but sponsor mergers and acquisitions have been a
major concern the past few years.

The premise of LSF/MM/BPF is to provide a venue where the right people
can talk low-latency, face to face. Without the distractions of a 1000
person event setting. The reason LSF/MM/BPF has been free to attend has
been to ensure that attendance fees wouldn't be a deterrent for the
people who should be there. The downside is that the invitation process
has been a deterrent for other, likely valuable, contributors.

I would love for LSF/MM/BPF/BBQ to be an umbrella event like LPC where
we could have miniconfs with all the relevant contributors for each
topic area to be present. The addition of the 3rd day was done to
facilitate that so that XFS folks, btrfs folks, etc. could congregate in
a room to discuss things only they cared about. But the current
attendance headcount cap means that not all topics can be covered due to
crucial people missing.

Also, there are several areas where I do think that the present LSF/MM
format still has merit. First of all, not all topics are large enough to
justify an entire miniconf or topic-specific workshop. We have many
topics that can be covered in an hour or less and that's the end of
that. The other aspect is that key people straddle multiple filesystems,
subsystems, etc. If we *only* had XFS/btrfs/BPF miniconfs, scheduling
would be near impossible. Hence the current division between scheduled
days and workshop day. Also, we do have cross-track topics that need
involvement across the board. I would personally be happy with 1 track
day and 2 workshop days if we could get critical mass for the workshop
topics.

In the old days, when LSF tracks were 10-12 people each, I felt we got
stuff done. Since then we have more than doubled the headcount for each
track in an attempt to get more people involved. But I feel that the
discussions are much less useful. Despite enforcing the no-slides rules,
etc.

If we combine sponsor funding with per-attendee fees to facilitate a
larger event, the question becomes: What should the headcount limit be?
200? 500? The reason I ask is that I think funding can be worked
out. But I also think it is important enough that we don't exceed the
"productive group size" too much for a given topic. And we usually put
that somewhere between 10 and 15. It is very rare to see more than this
many attendees actively participate in a discussion. This means for an
attendee cap of 200, we should aim to have ~20 concurrent topics
happening for it to be productive. Maybe slash that number in half to
compensate for the people in the hallway tracks?

One thing a few of us discussed a year or two ago was to have actual
per-session headcount limits. And make people bid on the sessions they
wanted to participate in and then cap each session at 15. That would
obviously be very hard to schedule and enforce. But I still think we
need to think about how we can bring N hundred people together and make
sure they congregate in productive groups of 10-15. That's really the
key as far as I'm concerned. We have tried the pure unconference
approach and that wasn't very productive either. So we need to land
somewhere in the middle...

-- 
Martin K. Petersen	Oracle Linux Engineering

Powered by blists - more mailing lists