linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Nikula <jarkko.nikula@bitmer.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>, Xiao Jiang <jgq516@gmail.com>,
	linux-omap@vger.kernel.org
Subject: Re: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
Date: Thu, 31 May 2012 11:23:17 +0300	[thread overview]
Message-ID: <4FC72A75.7050107@bitmer.com> (raw)
In-Reply-To: <4FC71705.80704@ti.com>

On 05/31/2012 10:00 AM, Tomi Valkeinen wrote:
>> One simple - wait for next merge window. It's not that long. Only ~3
>> months and meanwhile one could keep boss/customer/wife/whatever
>> satisfied by carrying patches in own tree :-)
> 
> Well... I'm not sure how serious you are here =).
> 
Quite serious :-)

> In some cases that's doable, and we've done it, for example omapdrm had
> some things delayed until next merge window, so it's definitely an option.
> 
> But it's quite easy to get some build dependencies between pull
> requests, so we'd be delaying features all the time. And sometimes even
> cross dependencies. In the worst case it could end up with delaying some
> features for a year to get all single pieces in bit by bit.
> 
Something what is usually done is to get ack from maintainers and let
code to be merged via another tree. Needs careful planning though in
order to avoid preventing e.g. API changes in one subsystem.

> Something I think we could try to do is create some kinds of temporary
> dummy functions or such which allow the compilation, but of course makes
> the component not (fully) functional. The temp functions could then be
> removed in -rc2 or so, when the dependencies are all there. But doesn't
> feel like an optimal solution either...
> 
Yeah, this might work too.

-- 
Jarkko


      reply	other threads:[~2012-05-31  8:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-30  7:14 Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI Xiao Jiang
2012-05-30 23:35 ` Ricardo Neri
2012-05-31  4:27   ` Xiao Jiang
2012-06-05  1:24     ` Ricardo Neri
2012-06-05  4:15       ` Xiao Jiang
2012-06-05 15:51         ` Ricardo Neri
2012-06-06  3:01           ` Xiao Jiang
2012-05-31  5:41   ` Jarkko Nikula
2012-05-31  6:31     ` Tomi Valkeinen
2012-05-31  6:42       ` Jarkko Nikula
2012-05-31  7:00         ` Tomi Valkeinen
2012-05-31  8:23           ` Jarkko Nikula [this message]

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=4FC72A75.7050107@bitmer.com \
    --to=jarkko.nikula@bitmer.com \
    --cc=jgq516@gmail.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=ricardo.neri@ti.com \
    --cc=tomi.valkeinen@ti.com \
    /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).