bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Matthew Wilcox <willy@infradead.org>,
	Josef Bacik <josef@toxicpanda.com>,
	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: Fri, 06 Mar 2020 14:07:47 -0500	[thread overview]
Message-ID: <yq1eeu51ev0.fsf@oracle.com> (raw)
In-Reply-To: <20200306180618.GN31668@ziepe.ca> (Jason Gunthorpe's message of "Fri, 6 Mar 2020 14:06:18 -0400")


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

  reply	other threads:[~2020-03-06 19:08 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 [this message]
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
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=yq1eeu51ev0.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bpf@vger.kernel.org \
    --cc=jgg@ziepe.ca \
    --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 \
    --cc=willy@infradead.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).