All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: Plumbers: Please split audio topics into separate sessions
Date: Mon, 06 Aug 2012 22:11:44 +0200	[thread overview]
Message-ID: <50202500.5060607@canonical.com> (raw)
In-Reply-To: <s5hwr1bizuj.wl%tiwai@suse.de>

On 08/06/2012 09:29 PM, Takashi Iwai wrote:
> At Mon, 06 Aug 2012 21:09:24 +0200,
> David Henningsson wrote:
>>
>> Looking at:
>>
>> http://summit.linuxplumbersconf.org/lpc-2012/track/lpc2012-audio/
>>
>> 45 minutes is not enough to handle two topics:
>>
>> Audio uConf: HD-audio cooking && QA/Testing
>> Audio uConf: Expose Routing && DSPs in ASoC
>> Audio uConf: Time Alignment && PA on Android
>>
>> Please split these three sessions into six. It is better to have a
>> little more time than necessary (even if I believe we easily fill 45
>> minutes per topic), than having to skip a topic just because the other
>> topic took more time than expected.
>
> Well, as already announced, each topic was planned to be about 20
> minutes, so I don't think we need to extend session time.

Judging from our last experience, where we had a two-hour session on 
Sunday and then had to reschedule on Wednesday for two more hours, and 
yet had to cancel the topic I was about to introduce, because everybody 
was tired (and waiting for lunch), I certainly beg to differ!

Besides, I don't remember seeing such a 20 minute announcement. But 
maybe I missed it.

> Skipping a topic can be avoided simply by looking at the clock, and
> cut at 20 minutes.

Given the talkative crowd that we are, that might not be so simple ;-)

> Each topic isn't expected to be a big "show" at all.  We hope each the
> topic leader shows a couple of slides at most to state the problem and
> the possible solution, and then leads the discussions.
> Of course, it's possible to ask more slots, if you are sure that one
> topic would need really 40 minutes discussions.

It's the discussions that take time.

Also all of the 45 minutes is not effective discussion/presentation 
time: Assume that we first wait 5 minutes for all people to appear, then 
we have 5 minutes presentation and 15 - 20 minutes discussion for the 
first topic, then 5 minutes are spent fiddling with the projector to 
show the slides for the second topic...and suddenly there is just a few 
minutes left for discussion of the second topic.

Maybe it can be done in 20 minutes in theory, and everything goes as 
planned, but it is very overly optimistic.

Also; we fly across half the world to get there, to spend just a few 
minutes talking? Better have some margins. Maybe some session will end 
early, but will it hurt? No. If we miss a topic, or have to cut it short 
without a conclusion, will it hurt? Yes.

> BTW, there is one more slot, planned for my topic for channel mapping
> API.  This can be used also for the pending issues, for example.

Given how the scheduler works - it tries to make sure required 
participants are not scheduled to two meetings simultaneously - 
switching topics and sessions around is going to confuse both people and 
the scheduler algorithm.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

  reply	other threads:[~2012-08-06 19:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-06 19:09 Plumbers: Please split audio topics into separate sessions David Henningsson
2012-08-06 19:29 ` Takashi Iwai
2012-08-06 20:11   ` David Henningsson [this message]
2012-08-06 22:24     ` Mark Brown
2012-08-07  5:58       ` Takashi Iwai
2012-08-07  6:28         ` Vinod Koul
2012-08-07  6:41         ` David Henningsson
2012-08-07  7:11           ` Takashi Iwai
2012-08-07  8:08             ` David Henningsson
2012-08-07  8:35               ` Takashi Iwai
2012-08-07 11:19                 ` David Henningsson
2012-08-07 11:15               ` Mark Brown
2012-08-07 11:26                 ` David Henningsson
2012-08-07 13:57                   ` Mark Brown
2012-08-07 14:04                     ` Takashi Iwai
2012-08-07 14:06                       ` Mark Brown
2012-08-06 19:38 ` Mark Brown
2012-08-06 20:14   ` David Henningsson
2012-08-06 21:45     ` Mark Brown
2012-08-07  6:42   ` Vinod Koul
2012-08-07  7:14     ` Takashi Iwai
2012-08-07 14:07     ` Mark Brown

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=50202500.5060607@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=tiwai@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.