Message-ID: <20200306194843.GA12490@mit.edu>
Date:   Fri, 6 Mar 2020 14:48:43 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Josef Bacik <josef@...icpanda.com>
Cc:     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

On Fri, Mar 06, 2020 at 11:08:36AM -0500, Josef Bacik wrote:
> 
> I'd be down for this.  Would you leave the thing open so anybody can
> register, or would you still have an invitation system?  I really, really
> despise the invitation system just because it's inherently self limiting.
> However I do want to make sure we are getting relevant people in the room,
> and not making it this "oh shit, I forgot to register, and now the
> conference is full" sort of situations.  Thanks,

There are lots of different ways it can be done.  The Maintainer's
Summit is an invite-only half-day event.  That's mainly because it's
about development processes, and there are lots of people who have a
strong interest in that, but we want to keep it done to small number
of people so we can have real conversations.

At Plumbers, the miniconfs leads can give a list of (six?) people they
really want to be present.  A few get free registration; the others
get guaranteed registrations thus bypassing the waitlist.  One of the
problems is that the miniconf leads don't always get the list of
people to the planning committee until late in the process, which made
the waitlist management problem even more painful.  At the miniconf,
there is social pressure so that the key attendees are seated near the
front of the room, and there might be audience of a few hundred that
are in listen-mostly mode, but for most technical topics, that isn't
that much of a problem.

I've also seen other cases where the room is small, and there is a
list of people who have guaranteed access to the room, and everyone
else (up to the fire limit) might have to sit or stand against the
wall, etc.

If we have a conference with many tracks, the different tracks can
have different admittance policies, such is as the case with the
Maintainer's Summit, Kernel Summit, Miniconfs, etc.  So that's
something which I think can be negotiated.

I suspect that for most of the LSF/MM contential topics, I doubt we
would have hundreds of people clamoring to get in on a discussion
about to handle, say, clearing DAX flag on files that might still be
in use by some RDMA drive.  That is *such* a fascinating topic, but I
doubt there really will be a need to limit attendance.  :-)

      	    	   	     	     - Ted

P.S.  I do need to note that there is one big advantage to invite-only
summts such as the LSF/MM and the old-style Kernel Summit.  Companies
who really want to present about, say, dual-actuator HDD's, or the
latest NVMe / Open Channel interface, are much more likely to pay $$$
to get access to an invite-only event.  When we moved to the
process-only Maintainer's Summit, and the Kernel Summit for the
technical tracks, it most definitely hurt the amount of sponsorship
dollars that we got for the Maintainer's Summit.

That's not a bad thing, but it might mean that we will need to cut
costs by drafting behind the LF, and maybe not having as nice evening
receptions, or as nice attendee gifts like we used to do in the early
years of the Kernel Summit.  Personally, I think that's *fine*; it's
the collaboration with fellow developers which is highest on my list
of priorities, and not the opportunities for fine dining or going to
fun cities.  And if giving up on some of these amenities means that I
can bring some of the more junior engineers on my team so they can
meet other file system developers, I'm **all** for it.  But for some
folks, they may view this tradeoff as a loss.

Powered by blists - more mailing lists