Re: [Lsf-pc] XFS BoF at LSFMM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 09, 2024 at 08:29:19PM +0300, Amir Goldstein wrote:
> On Thu, May 9, 2024 at 6:55 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
> >
> > [adds ritesh to cc]
> >
> > On Thu, May 09, 2024 at 08:23:25AM +0300, Amir Goldstein wrote:
> > > On Thu, May 9, 2024 at 8:06 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> > > >
> > > > On Thu, May 09, 2024 at 08:01:39AM +0300, Amir Goldstein wrote:
> > > > >
> > > > > FYI, I counted more than 10 attendees that are active contributors or
> > > > > have contributed to xfs in one way or another.
> > > > > That's roughly a third of the FS track.
> > > >
> > > > FYI, I'm flying out at 4:15pm on Wednesday, and while I try to keep my
> > > > time at the airport short I'd still be gone by 3:30.
> > >
> > > I've penciled XFS BoF at 2:30
> >
> > Ritesh and Ted and Jan and I were chatting during the ext4 concall just
> > now.  Could we have a 30 minute iomap bof at 2:30pm followed by the XFS
> > bof after that?  That would give us some time to chat with hch about
> > iomap (and xfs) direction before he has to leave.
> >
> > Alternately, we could announce a lunchtime discussion group on Monday
> > following Ritesh's presentation about iomap.  That could fit everyone's
> > schedule better?  Also everyone's braincaches will likely be warmer.
> >
> 
> Seems to me that there will be a wider interest in iomap BoF
> Not sure what you mean by lunchtime discussion.

Monday 90-minute lunch is posted as being in "Grand ballroom C", so I
would tell everyone to come find the table(s) I'm sitting at for a
discussion over lunch.  We can move out to a hallway after everyone's
done eating.

> We can move Willy's GFP_NOFS talk to 15:30 and have the iomap BoF
> after Ritesh's session.

<shrug> If you like, though I don't think it's totally necessary.  But
you might have a better idea of what the venue is like than I do, so
I'll let you make that call. :)

> > > >
> > > > But that will only matter if you make the BOF and actual BOF and not the
> > > > usual televised crap that happens at LSFMM.
> > > >
> > >
> > > What happens in XFS BoF is entirely up to the session lead and attendees
> > > to decide.
> > >
> > > There is video in the room, if that is what you meant so that remote attendees
> > > that could not make it in person can be included.
> > >
> > > We did not hand out free virtual invites to anyone who asked to attend.
> > > Those were sent very selectively.
> > >
> > > Any session lead can request to opt-out from publishing the video of the
> > > session publicly or to audit the video before it is published.
> > > This was the same last year and this year this was explicitly mentioned
> > > in the invitation:
> > >
> > > "Please note: As with previous years there will be an A/V team on-
> > > site in order to facilitate conferencing and help with virtual
> > > participants. In order to leave room for off-the-record discussions
> > > the storage track completely opts out of recordings. For all other
> > > tracks, please coordinate with your track leads (mentioned below)
> > > whether a session should explicitly opt-out. This can also be
> > > coordinated on-site during or after the workshop. The track leads
> > > then take care that the given session recording will not be
> > > published."
> > >
> > > I will take a note to keep XFS BoF off the record if that is what you
> > > want and if the other xfs developers do not object.
> >
> > Survey: How many people want to attend the xfs bof virtually?
> >
> > I'd be ok with an OTR discussion with no video, though I reserve the
> > right to change my mind if the score becomes chair: 2 djwong: 0. :P
> 
> The middle ground is to allow video for the selective virtual attendees
> (and trust them not to record and publish) and not publish the video
> on LSMFF site.

I didn't know that was also an option; I'll keep that in mind.

--D

> Thanks,
> Amir.
> 




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux