Linux Media Controller development
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans Verkuil <hverkuil+cisco@kernel.org>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Subject: Re: [RFC] Media Summit 2027: one or two days?
Date: Wed, 11 Nov 2026 16:21:58 +0200	[thread overview]
Message-ID: <20261111142158.GA192350@killaraus.ideasonboard.com> (raw)
In-Reply-To: <adeb9e3e-ba93-420f-a9c6-f56a7d3b6bbf@kernel.org>

Hi Hans,

On Wed, Nov 11, 2026 at 11:12:00AM +0100, Hans Verkuil wrote:
> Hi all,
> 
> I propose to again co-locate the Media Summit 2027 with Embedded Recipes:

Thank you for taking the lead in organizing the media summit once again.

> https://embedded-recipes.org/2027/
> 
> That conference is on May 27-28 (Thursday and Friday), again in Nice, France, but at a
> different venue.
> 
> I have three questions:
> 
> 1) Should we use the same meeting room again in hotel Campanile? I really liked that meeting
> room, and the price was reasonable. It is a 20 minute bus ride from the new ER venue, so
> that's not too bad.

It was convenient. The main downside was the very limited interesting
lunch options around, so we may end up in the same restaurant again.
It's not a good enough reason to move to a different venue, so no
objection against the Campanile.

> 2) Should we do a two day summit? The Media Summit from this year really had too many
> topics and we had to rush at the end. So either we stick to one day and I have to be
> more strict with regards to the number of topics, or we expand to two days, but keep it
> shorter (e.g. start at 10 AM, stop at 17 AM or earlier). Stopping earlier also makes
> it possible to split off in smaller groups if there are specific issues (not directly
> part of the Summit) that people want to discuss.

This is a more tricky question. Two days is a lot in a crowded week. I
understand that Embedded Recipes will be part of an "Embedded Week"
again next year (and this overlaps with the third point below).

We definitely ran out of time last year.  I'd argue it was caused by not
just the number of topics, but also their nature. There were quite a few
topics that were of interest to only a very limited number of people in
the audience. Part of the trouble is that there are a few core people
who are interested in most topics, so splitting in two groups for half
of the day would likely not be a great solution either.

I wonder if we should try the LPC style, where sessions focus on
discussions instead of presentations. Some of the topics this year had a
long presentation for limited discussions. This would require topic
leads to submit the presentation ahead of time (with a very strict
deadline of at least a week before the event) in order for all attendees
to have a chance to read through presentations.

This wouldn't forbid presentations completely, I think there's still a
need for them for topics that aim at informing the audience, not
gathering feedback.

> 3) When do we hold the summit? I.e. for a one-day summit do we pick May 25 or 26? For a
> two-day summit that would be May 24-25 or 25-26. I suspect there may be workshops on the
> Wednesday (May 26), so keeping the Wednesday free might be better. Nice is not the worst
> place to spend a day :-)

Yes, there will most likely be workshops, and we need to avoid
conflicting with them. I expect we'll organize a libcamera workshop
again. We need to align the agenda with the Embedded Recipes organizers.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2026-11-11 14:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11 10:12 [RFC] Media Summit 2027: one or two days? Hans Verkuil
2026-11-11 14:21 ` Laurent Pinchart [this message]
2026-11-11 14:30 ` Ricardo Ribalda Delgado

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=20261111142158.GA192350@killaraus.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=hverkuil+cisco@kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.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