bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
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: Fri, 6 Mar 2020 14:48:43 -0500	[thread overview]
Message-ID: <20200306194843.GA12490@mit.edu> (raw)
In-Reply-To: <72708005-0810-1957-1e58-5b70779ab6db@toxicpanda.com>

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.

  reply	other threads:[~2020-03-06 19:49 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 [this message]
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
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=20200306194843.GA12490@mit.edu \
    --to=tytso@mit.edu \
    --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).