Remove DeviceManager and DeviceInfo.

Remove DeviceManager and DeviceInfo.

BUG=webrtc:5615, webrtc:5620
Committed: https://crrev.com/8ad582d83ffb935ba06b2474d1ec1ff3650ac376
Cr-Commit-Position: refs/heads/master@{#12020}

[the sun, 2016-02-19 22:00:45]

Description was changed from

==========
Remove DeviceManager.

BUG=
==========

to

==========
Remove DeviceManager and DeviceInfo.

BUG=
==========

[the sun, 2016-02-19 22:00:46]

solenberg@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[the sun, 2016-02-19 22:08:17]

Is this ripe for picking? Seems only used by examples/peerconnection/client

[pthatcher1, 2016-02-20 06:16:00]

lgtm

Except please make sure HarmonyInternal::CreateVideoCapturer can easily switch
over and they are warned.

https://codereview.webrtc.org/1715883002/diff/80001/webrtc/media/devices/devi...
File webrtc/media/devices/devicemanager.h (left):

https://codereview.webrtc.org/1715883002/diff/80001/webrtc/media/devices/devi...
webrtc/media/devices/devicemanager.h:147: virtual VideoCapturer*
CreateVideoCapturer(const Device& device) const;
This is still being used by HarmonyInternal::CreateVideoCapturer.   I believe
they can switch to using a  WebRtcVideoDeviceCapturerFactory instead, but they
are currently calling this method.  Perhaps talk to noahric@ or thaloun@ about
it.

[the sun, 2016-03-01 18:12:23]

The CQ bit was checked by solenberg@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-01 18:12:28]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1715883002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1715883002/120001

[the sun, 2016-03-01 18:17:50]

On 2016/02/20 06:16:00, pthatcher1 wrote:
> lgtm
> 
> Except please make sure HarmonyInternal::CreateVideoCapturer can easily switch
> over and they are warned.
> 
>
https://codereview.webrtc.org/1715883002/diff/80001/webrtc/media/devices/devi...
> File webrtc/media/devices/devicemanager.h (left):
> 
>
https://codereview.webrtc.org/1715883002/diff/80001/webrtc/media/devices/devi...
> webrtc/media/devices/devicemanager.h:147: virtual VideoCapturer*
> CreateVideoCapturer(const Device& device) const;
> This is still being used by HarmonyInternal::CreateVideoCapturer.   I believe
> they can switch to using a  WebRtcVideoDeviceCapturerFactory instead, but they
> are currently calling this method.  Perhaps talk to noahric@ or thaloun@ about
> it.

Except for that, are you ok with the change? Note that it touches
webrtc/examples/peerconnection/client/conductor.cc - not sure whether that is
live or dead code, but it does look rather zombie-like...

[the sun, 2016-03-01 19:44:31]

Description was changed from

==========
Remove DeviceManager and DeviceInfo.

BUG=
==========

to

==========
Remove DeviceManager and DeviceInfo.

BUG=webrtc:5615
==========

[commit-bot: I haz the power, 2016-03-01 20:13:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-01 20:13:23]

Dry run: Try jobs failed on following builders:
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  win_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[the sun, 2016-03-01 20:43:05]

The CQ bit was checked by solenberg@webrtc.org

[the sun, 2016-03-01 20:43:05]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1715883002/#ps120001 (title:
"rebase")

[commit-bot: I haz the power, 2016-03-01 20:43:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1715883002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1715883002/120001

[commit-bot: I haz the power, 2016-03-01 20:46:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-01 20:46:56]

Try jobs failed on following builders:
  presubmit on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/3805)

[kjellander_webrtc, 2016-03-01 20:56:37]

kjellander@webrtc.org changed reviewers:
+ kjellander@webrtc.org

[kjellander_webrtc, 2016-03-01 20:56:38]

Got a few questions.

Pro tip for compile-only CLs: mark them with NOTRY=True and use an alias like
this to trigger only compilation (since no tests needs to run):
alias trycompile='git cl try --bot=win_x64_gn_rel --bot=win_x64_gn_dbg
--bot=win_x64_clang_rel --bot=win_x64_clang_dbg --bot=win_compile_x64_rel
--bot=win_compile_rel --bot=win_compile_dbg --bot=win_compile_x64_dbg
--bot=win_clang_rel --bot=mac_gn_rel --bot=mac_gn_dbg --bot=win_clang_dbg
--bot=linux_gn_rel --bot=mac_compile_dbg --bot=mac_compile_rel
--bot=linux_compile_rel --bot=linux_gn_dbg --bot=ios_rel --bot=linux_compile_dbg
--bot=ios_arm64_dbg --bot=ios_arm64_rel --bot=ios_dbg --bot=ios64_sim_dbg
--bot=ios32_sim_dbg --bot=android_gn_rel --bot=android_gn_dbg
--bot=android_compile_x86_dbg --bot=android_compile_x64_dbg
--bot=android_compile_dbg --bot=android_compile_arm64_rel
--bot=android_compile_rel --bot=android_compile_arm64_dbg
--bot=android_clang_dbg -m tryserver.webrtc'

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
File webrtc/media/media.gyp (left):

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
Does it make any sense to keep these few files around? Everything else for
include_internal_device_management==1 is dropped.

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
webrtc/media/media.gyp:224: ['OS=="mac" and
include_internal_device_management==1', {
If you're dropping all the device manager sources (depending on previous
comment), please also remove the variable from webrtc/build/common.gypi and all
the blocks in this GYP file.

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
webrtc/media/media.gyp:242: 'link_settings': {
These link_settings belonged only to the code you remove above, so they should
also be removed.

[kjellander_webrtc, 2016-03-01 20:59:22]

On 2016/03/01 20:56:38, kjellander (webrtc) wrote:
> Got a few questions.
> 
> Pro tip for compile-only CLs: mark them with NOTRY=True and use an alias like
> this to trigger only compilation (since no tests needs to run):
> alias trycompile='git cl try --bot=win_x64_gn_rel --bot=win_x64_gn_dbg
> --bot=win_x64_clang_rel --bot=win_x64_clang_dbg --bot=win_compile_x64_rel
> --bot=win_compile_rel --bot=win_compile_dbg --bot=win_compile_x64_dbg
> --bot=win_clang_rel --bot=mac_gn_rel --bot=mac_gn_dbg --bot=win_clang_dbg
> --bot=linux_gn_rel --bot=mac_compile_dbg --bot=mac_compile_rel
> --bot=linux_compile_rel --bot=linux_gn_dbg --bot=ios_rel
--bot=linux_compile_dbg
> --bot=ios_arm64_dbg --bot=ios_arm64_rel --bot=ios_dbg --bot=ios64_sim_dbg
> --bot=ios32_sim_dbg --bot=android_gn_rel --bot=android_gn_dbg
> --bot=android_compile_x86_dbg --bot=android_compile_x64_dbg
> --bot=android_compile_dbg --bot=android_compile_arm64_rel
> --bot=android_compile_rel --bot=android_compile_arm64_dbg
> --bot=android_clang_dbg -m tryserver.webrtc'
> 
> https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
> File webrtc/media/media.gyp (left):
> 
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
> Does it make any sense to keep these few files around? Everything else for
> include_internal_device_management==1 is dropped.
> 
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> webrtc/media/media.gyp:224: ['OS=="mac" and
> include_internal_device_management==1', {
> If you're dropping all the device manager sources (depending on previous
> comment), please also remove the variable from webrtc/build/common.gypi and
all
> the blocks in this GYP file.
> 
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> webrtc/media/media.gyp:242: 'link_settings': {
> These link_settings belonged only to the code you remove above, so they should
> also be removed.

Also, be aware that submitting this will break the bots in 
https://build.chromium.org/p/chromium.webrtc.fyi/waterfall
because of
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjin...
so make sure you have a roll-CL prepared to submit quickly and/or coordinate
with the sheriff.

[the sun, 2016-03-01 21:14:09]

On 2016/03/01 20:59:22, kjellander (webrtc) wrote:
> On 2016/03/01 20:56:38, kjellander (webrtc) wrote:
> > Got a few questions.
> > 
> > Pro tip for compile-only CLs: mark them with NOTRY=True and use an alias
like
> > this to trigger only compilation (since no tests needs to run):
> > alias trycompile='git cl try --bot=win_x64_gn_rel --bot=win_x64_gn_dbg
> > --bot=win_x64_clang_rel --bot=win_x64_clang_dbg --bot=win_compile_x64_rel
> > --bot=win_compile_rel --bot=win_compile_dbg --bot=win_compile_x64_dbg
> > --bot=win_clang_rel --bot=mac_gn_rel --bot=mac_gn_dbg --bot=win_clang_dbg
> > --bot=linux_gn_rel --bot=mac_compile_dbg --bot=mac_compile_rel
> > --bot=linux_compile_rel --bot=linux_gn_dbg --bot=ios_rel
> --bot=linux_compile_dbg
> > --bot=ios_arm64_dbg --bot=ios_arm64_rel --bot=ios_dbg --bot=ios64_sim_dbg
> > --bot=ios32_sim_dbg --bot=android_gn_rel --bot=android_gn_dbg
> > --bot=android_compile_x86_dbg --bot=android_compile_x64_dbg
> > --bot=android_compile_dbg --bot=android_compile_arm64_rel
> > --bot=android_compile_rel --bot=android_compile_arm64_dbg
> > --bot=android_clang_dbg -m tryserver.webrtc'
> > 
> > https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
> > File webrtc/media/media.gyp (left):
> > 
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
> > Does it make any sense to keep these few files around? Everything else for
> > include_internal_device_management==1 is dropped.
> > 
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > webrtc/media/media.gyp:224: ['OS=="mac" and
> > include_internal_device_management==1', {
> > If you're dropping all the device manager sources (depending on previous
> > comment), please also remove the variable from webrtc/build/common.gypi and
> all
> > the blocks in this GYP file.
> > 
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > webrtc/media/media.gyp:242: 'link_settings': {
> > These link_settings belonged only to the code you remove above, so they
should
> > also be removed.
> 
> Also, be aware that submitting this will break the bots in 
> https://build.chromium.org/p/chromium.webrtc.fyi/waterfall
> because of
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjin...
> so make sure you have a roll-CL prepared to submit quickly and/or coordinate
> with the sheriff.

Ooh, thanks! I'll get that sorted first then.

[the sun, 2016-03-01 21:14:59]

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
File webrtc/media/media.gyp (left):

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> Does it make any sense to keep these few files around? Everything else for
> include_internal_device_management==1 is dropped.

Right, as a matter of fact, I already have a CL lined up to remove them:
https://codereview.webrtc.org/1751583002/

Would you like me to do it (and remove the gyp flag) in this CL instead?

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
webrtc/media/media.gyp:224: ['OS=="mac" and
include_internal_device_management==1', {
On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> If you're dropping all the device manager sources (depending on previous
> comment), please also remove the variable from webrtc/build/common.gypi and
all
> the blocks in this GYP file.

See above comment.

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
webrtc/media/media.gyp:242: 'link_settings': {
On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> These link_settings belonged only to the code you remove above, so they should
> also be removed.

No, I get link errors elsewhere, but lazy me didn't figure out exactly why and
where, so I'll repent and do that.

[kjellander_webrtc, 2016-03-01 21:31:30]

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
File webrtc/media/media.gyp (left):

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
On 2016/03/01 21:14:59, the sun wrote:
> On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > Does it make any sense to keep these few files around? Everything else for
> > include_internal_device_management==1 is dropped.
> 
> Right, as a matter of fact, I already have a CL lined up to remove them:
> https://codereview.webrtc.org/1751583002/
> 
> Would you like me to do it (and remove the gyp flag) in this CL instead?

Ah, it doesn't matter to me, but it won't make this one harder to review so
including it here might make more sense.

https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
webrtc/media/media.gyp:242: 'link_settings': {
On 2016/03/01 21:14:59, the sun wrote:
> On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > These link_settings belonged only to the code you remove above, so they
should
> > also be removed.
> 
> No, I get link errors elsewhere, but lazy me didn't figure out exactly why and
> where, so I'll repent and do that.

Oh, you're probably right. I probably made that mistake in
https://codereview.webrtc.org/1693803002/ then. These things should have been
inside a condition with only OS=="mac" then.

[the sun, 2016-03-01 22:20:43]

On 2016/03/01 21:31:30, kjellander (webrtc) wrote:
> https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
> File webrtc/media/media.gyp (left):
> 
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
> On 2016/03/01 21:14:59, the sun wrote:
> > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > Does it make any sense to keep these few files around? Everything else for
> > > include_internal_device_management==1 is dropped.
> > 
> > Right, as a matter of fact, I already have a CL lined up to remove them:
> > https://codereview.webrtc.org/1751583002/
> > 
> > Would you like me to do it (and remove the gyp flag) in this CL instead?
> 
> Ah, it doesn't matter to me, but it won't make this one harder to review so
> including it here might make more sense.
> 
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> webrtc/media/media.gyp:242: 'link_settings': {
> On 2016/03/01 21:14:59, the sun wrote:
> > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > These link_settings belonged only to the code you remove above, so they
> should
> > > also be removed.
> > 
> > No, I get link errors elsewhere, but lazy me didn't figure out exactly why
and
> > where, so I'll repent and do that.
> 
> Oh, you're probably right. I probably made that mistake in
> https://codereview.webrtc.org/1693803002/ then. These things should have been
> inside a condition with only OS=="mac" then.

Decided to leave the libudev code removal in a separate CL. That also means the
include_internal_device_management flag will be fully removed there instead.

Tracked down a solution for the link error but I'm not sure it makes much more
sense to me. Maybe you have a better idea of where the OpenGL framework should
be added for Mac builds?

[kjellander_webrtc, 2016-03-02 06:21:15]

On 2016/03/01 22:20:43, the sun wrote:
> On 2016/03/01 21:31:30, kjellander (webrtc) wrote:
> > https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
> > File webrtc/media/media.gyp (left):
> > 
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
> > On 2016/03/01 21:14:59, the sun wrote:
> > > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > > Does it make any sense to keep these few files around? Everything else
for
> > > > include_internal_device_management==1 is dropped.
> > > 
> > > Right, as a matter of fact, I already have a CL lined up to remove them:
> > > https://codereview.webrtc.org/1751583002/
> > > 
> > > Would you like me to do it (and remove the gyp flag) in this CL instead?
> > 
> > Ah, it doesn't matter to me, but it won't make this one harder to review so
> > including it here might make more sense.
> > 
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > webrtc/media/media.gyp:242: 'link_settings': {
> > On 2016/03/01 21:14:59, the sun wrote:
> > > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > > These link_settings belonged only to the code you remove above, so they
> > should
> > > > also be removed.
> > > 
> > > No, I get link errors elsewhere, but lazy me didn't figure out exactly why
> and
> > > where, so I'll repent and do that.
> > 
> > Oh, you're probably right. I probably made that mistake in
> > https://codereview.webrtc.org/1693803002/ then. These things should have
been
> > inside a condition with only OS=="mac" then.
> 
> Decided to leave the libudev code removal in a separate CL. That also means
the
> include_internal_device_management flag will be fully removed there instead.

That seems to be the easiest path, yes.

 
> Tracked down a solution for the link error but I'm not sure it makes much more
> sense to me. Maybe you have a better idea of where the OpenGL framework should
> be added for Mac builds?

I don't know, but reverting the link_settings block to as how it was before
https://codereview.webrtc.org/1693803002/ must work, no?

[the sun, 2016-03-02 09:38:52]

On 2016/03/02 06:21:15, kjellander (webrtc) wrote:
> On 2016/03/01 22:20:43, the sun wrote:
> > On 2016/03/01 21:31:30, kjellander (webrtc) wrote:
> > >
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
> > > File webrtc/media/media.gyp (left):
> > > 
> > >
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > > webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
> > > On 2016/03/01 21:14:59, the sun wrote:
> > > > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > > > Does it make any sense to keep these few files around? Everything else
> for
> > > > > include_internal_device_management==1 is dropped.
> > > > 
> > > > Right, as a matter of fact, I already have a CL lined up to remove them:
> > > > https://codereview.webrtc.org/1751583002/
> > > > 
> > > > Would you like me to do it (and remove the gyp flag) in this CL instead?
> > > 
> > > Ah, it doesn't matter to me, but it won't make this one harder to review
so
> > > including it here might make more sense.
> > > 
> > >
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > > webrtc/media/media.gyp:242: 'link_settings': {
> > > On 2016/03/01 21:14:59, the sun wrote:
> > > > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > > > These link_settings belonged only to the code you remove above, so
they
> > > should
> > > > > also be removed.
> > > > 
> > > > No, I get link errors elsewhere, but lazy me didn't figure out exactly
why
> > and
> > > > where, so I'll repent and do that.
> > > 
> > > Oh, you're probably right. I probably made that mistake in
> > > https://codereview.webrtc.org/1693803002/ then. These things should have
> been
> > > inside a condition with only OS=="mac" then.
> > 
> > Decided to leave the libudev code removal in a separate CL. That also means
> the
> > include_internal_device_management flag will be fully removed there instead.
> 
> That seems to be the easiest path, yes.
> 
>  
> > Tracked down a solution for the link error but I'm not sure it makes much
more
> > sense to me. Maybe you have a better idea of where the OpenGL framework
should
> > be added for Mac builds?
> 
> I don't know, but reverting the link_settings block to as how it was before
> https://codereview.webrtc.org/1693803002/ must work, no?

As discussed offline, filed
https://bugs.chromium.org/p/webrtc/issues/detail?id=5620 to call in OS X experts
to work out the right spot to link with the OpenGL framework; committing this CL
as it is.

[the sun, 2016-03-02 09:39:29]

The CQ bit was checked by solenberg@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-02 09:39:33]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1715883002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1715883002/180001

[kjellander_webrtc, 2016-03-02 10:03:24]

On 2016/03/02 09:38:52, the sun wrote:
> On 2016/03/02 06:21:15, kjellander (webrtc) wrote:
> > On 2016/03/01 22:20:43, the sun wrote:
> > > On 2016/03/01 21:31:30, kjellander (webrtc) wrote:
> > > >
> https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
> > > > File webrtc/media/media.gyp (left):
> > > > 
> > > >
> > >
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > > > webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
> > > > On 2016/03/01 21:14:59, the sun wrote:
> > > > > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > > > > Does it make any sense to keep these few files around? Everything
else
> > for
> > > > > > include_internal_device_management==1 is dropped.
> > > > > 
> > > > > Right, as a matter of fact, I already have a CL lined up to remove
them:
> > > > > https://codereview.webrtc.org/1751583002/
> > > > > 
> > > > > Would you like me to do it (and remove the gyp flag) in this CL
instead?
> > > > 
> > > > Ah, it doesn't matter to me, but it won't make this one harder to review
> so
> > > > including it here might make more sense.
> > > > 
> > > >
> > >
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > > > webrtc/media/media.gyp:242: 'link_settings': {
> > > > On 2016/03/01 21:14:59, the sun wrote:
> > > > > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > > > > These link_settings belonged only to the code you remove above, so
> they
> > > > should
> > > > > > also be removed.
> > > > > 
> > > > > No, I get link errors elsewhere, but lazy me didn't figure out exactly
> why
> > > and
> > > > > where, so I'll repent and do that.
> > > > 
> > > > Oh, you're probably right. I probably made that mistake in
> > > > https://codereview.webrtc.org/1693803002/ then. These things should have
> > been
> > > > inside a condition with only OS=="mac" then.
> > > 
> > > Decided to leave the libudev code removal in a separate CL. That also
means
> > the
> > > include_internal_device_management flag will be fully removed there
instead.
> > 
> > That seems to be the easiest path, yes.
> > 
> >  
> > > Tracked down a solution for the link error but I'm not sure it makes much
> more
> > > sense to me. Maybe you have a better idea of where the OpenGL framework
> should
> > > be added for Mac builds?
> > 
> > I don't know, but reverting the link_settings block to as how it was before
> > https://codereview.webrtc.org/1693803002/ must work, no?
> 
> As discussed offline, filed
> https://bugs.chromium.org/p/webrtc/issues/detail?id=5620 to call in OS X
experts
> to work out the right spot to link with the OpenGL framework; committing this
CL
> as it is.

Cool, make sure you prepare a Chromium roll+talk to the sheriff as it'll break
things in Chromium.

[kjellander_webrtc, 2016-03-02 10:04:29]

lgtm but please add webrtc:5620 to the description.

[the sun, 2016-03-02 10:22:25]

Description was changed from

==========
Remove DeviceManager and DeviceInfo.

BUG=webrtc:5615
==========

to

==========
Remove DeviceManager and DeviceInfo.

BUG=webrtc:5615, webrtc:5620
==========

[commit-bot: I haz the power, 2016-03-02 10:48:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-02 10:48:27]

Dry run: Try jobs failed on following builders:
  linux_libfuzzer_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_libfuzzer_rel/bui...)

[the sun, 2016-03-02 10:49:43]

On 2016/03/02 10:03:24, kjellander (webrtc) wrote:
> On 2016/03/02 09:38:52, the sun wrote:
> > On 2016/03/02 06:21:15, kjellander (webrtc) wrote:
> > > On 2016/03/01 22:20:43, the sun wrote:
> > > > On 2016/03/01 21:31:30, kjellander (webrtc) wrote:
> > > > >
> > https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp
> > > > > File webrtc/media/media.gyp (left):
> > > > > 
> > > > >
> > > >
> > >
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > > > > webrtc/media/media.gyp:171: 'devices/libudevsymboltable.cc',
> > > > > On 2016/03/01 21:14:59, the sun wrote:
> > > > > > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > > > > > Does it make any sense to keep these few files around? Everything
> else
> > > for
> > > > > > > include_internal_device_management==1 is dropped.
> > > > > > 
> > > > > > Right, as a matter of fact, I already have a CL lined up to remove
> them:
> > > > > > https://codereview.webrtc.org/1751583002/
> > > > > > 
> > > > > > Would you like me to do it (and remove the gyp flag) in this CL
> instead?
> > > > > 
> > > > > Ah, it doesn't matter to me, but it won't make this one harder to
review
> > so
> > > > > including it here might make more sense.
> > > > > 
> > > > >
> > > >
> > >
> >
>
https://codereview.webrtc.org/1715883002/diff/120001/webrtc/media/media.gyp#o...
> > > > > webrtc/media/media.gyp:242: 'link_settings': {
> > > > > On 2016/03/01 21:14:59, the sun wrote:
> > > > > > On 2016/03/01 20:56:37, kjellander (webrtc) wrote:
> > > > > > > These link_settings belonged only to the code you remove above, so
> > they
> > > > > should
> > > > > > > also be removed.
> > > > > > 
> > > > > > No, I get link errors elsewhere, but lazy me didn't figure out
exactly
> > why
> > > > and
> > > > > > where, so I'll repent and do that.
> > > > > 
> > > > > Oh, you're probably right. I probably made that mistake in
> > > > > https://codereview.webrtc.org/1693803002/ then. These things should
have
> > > been
> > > > > inside a condition with only OS=="mac" then.
> > > > 
> > > > Decided to leave the libudev code removal in a separate CL. That also
> means
> > > the
> > > > include_internal_device_management flag will be fully removed there
> instead.
> > > 
> > > That seems to be the easiest path, yes.
> > > 
> > >  
> > > > Tracked down a solution for the link error but I'm not sure it makes
much
> > more
> > > > sense to me. Maybe you have a better idea of where the OpenGL framework
> > should
> > > > be added for Mac builds?
> > > 
> > > I don't know, but reverting the link_settings block to as how it was
before
> > > https://codereview.webrtc.org/1693803002/ must work, no?
> > 
> > As discussed offline, filed
> > https://bugs.chromium.org/p/webrtc/issues/detail?id=5620 to call in OS X
> experts
> > to work out the right spot to link with the OpenGL framework; committing
this
> CL
> > as it is.
> 
> Cool, make sure you prepare a Chromium roll+talk to the sheriff as it'll break
> things in Chromium.

See: https://codereview.chromium.org/1760453002/

I was able to build Chromium Mac after removing DeviceManager from
libjingle.gyp.

[the sun, 2016-03-02 14:56:26]

The CQ bit was checked by solenberg@webrtc.org

[the sun, 2016-03-02 14:56:27]

The patchset sent to the CQ was uploaded after l-g-t-m from
pthatcher@webrtc.org, kjellander@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1715883002/#ps200001 (title:
"rebase")

[commit-bot: I haz the power, 2016-03-02 14:56:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1715883002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1715883002/200001

[the sun, 2016-03-02 15:51:41]

solenberg@webrtc.org changed reviewers:
+ tkchin@webrtc.org

[the sun, 2016-03-02 15:52:14]

On 2016/03/02 14:56:37, commit-bot: I haz the power wrote:
> CQ is trying da patch. Follow status at
>  https://chromium-cq-status.appspot.com/patch-status/1715883002/200001
> View timeline at
>  https://chromium-cq-status.appspot.com/patch-timeline/1715883002/200001

Adding tkchin@ for OWNERs approval of webrtc/examples/peerconnection/client/

[commit-bot: I haz the power, 2016-03-02 15:53:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-02 15:53:37]

Try jobs failed on following builders:
  presubmit on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/3822)

[tkchin_webrtc, 2016-03-02 21:13:37]

https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
File talk/app/webrtc/objc/RTCVideoCapturer.mm (left):

https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
talk/app/webrtc/objc/RTCVideoCapturer.mm:41: +
(RTCVideoCapturer*)capturerWithDeviceName:(NSString*)deviceName {
What is the new way of getting the cricket video capturer associated with a
device name?
Should not eliminate this code, but provide the new pathway first. (Otherwise
this class essentially becomes unusable; some third party folks might still be
using this)

https://codereview.webrtc.org/1715883002/diff/200001/webrtc/api/api.gyp
File webrtc/api/api.gyp (right):

https://codereview.webrtc.org/1715883002/diff/200001/webrtc/api/api.gyp#newco...
webrtc/api/api.gyp:340: # TODO(solenberg): Doesn't work adding the flag to
'rtc_api_objc'. Why?
try sticking it in an all_dependent_settings block like what the ios bits are
doing with opengles

[the sun, 2016-03-03 20:00:14]

Addressed your comments. PTAL.

Are you ok with the change to Conductor::OpenVideoCaptureDevice()?

https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
File talk/app/webrtc/objc/RTCVideoCapturer.mm (left):

https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
talk/app/webrtc/objc/RTCVideoCapturer.mm:41: +
(RTCVideoCapturer*)capturerWithDeviceName:(NSString*)deviceName {
On 2016/03/02 21:13:37, tkchin_webrtc wrote:
> What is the new way of getting the cricket video capturer associated with a
> device name?
> Should not eliminate this code, but provide the new pathway first. (Otherwise
> this class essentially becomes unusable; some third party folks might still be
> using this)

I'm now using WebRtcVideoDeviceCapturerFactory to directly create the capturer
(from device name).

Problem is, there does not appear to be any tests running the code. How do we
make sure it works? Is it worth writing up a test for just this part of the
"legacy API"?

https://codereview.webrtc.org/1715883002/diff/200001/webrtc/api/api.gyp
File webrtc/api/api.gyp (right):

https://codereview.webrtc.org/1715883002/diff/200001/webrtc/api/api.gyp#newco...
webrtc/api/api.gyp:340: # TODO(solenberg): Doesn't work adding the flag to
'rtc_api_objc'. Why?
On 2016/03/02 21:13:37, tkchin_webrtc wrote:
> try sticking it in an all_dependent_settings block like what the ios bits are
> doing with opengles

I didn't realize there were two targets with very similar lists of files:
rtc_api_objc and libjingle_peerconnection_objc that both needed the OpenGL
framework. Fixed now.

[tkchin_webrtc, 2016-03-04 01:18:35]

lgtm

I don't know anything about conductor.cc (not even what it does) - can you check
the git log and see who owns it?

https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
File talk/app/webrtc/objc/RTCVideoCapturer.mm (left):

https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
talk/app/webrtc/objc/RTCVideoCapturer.mm:41: +
(RTCVideoCapturer*)capturerWithDeviceName:(NSString*)deviceName {
On 2016/03/03 20:00:13, the sun wrote:
> On 2016/03/02 21:13:37, tkchin_webrtc wrote:
> > What is the new way of getting the cricket video capturer associated with a
> > device name?
> > Should not eliminate this code, but provide the new pathway first.
(Otherwise
> > this class essentially becomes unusable; some third party folks might still
be
> > using this)
> 
> I'm now using WebRtcVideoDeviceCapturerFactory to directly create the capturer
> (from device name).
> 
> Problem is, there does not appear to be any tests running the code. How do we
> make sure it works? Is it worth writing up a test for just this part of the
> "legacy API"?

Nah, not worth adding a test for this. I've patched your CL and verified that it
works, thank you for adding it.

https://codereview.webrtc.org/1715883002/diff/220001/talk/app/webrtc/objc/RTC...
File talk/app/webrtc/objc/RTCVideoCapturer.mm (right):

https://codereview.webrtc.org/1715883002/diff/220001/talk/app/webrtc/objc/RTC...
talk/app/webrtc/objc/RTCVideoCapturer.mm:43: cricket::Device
device(std::string([deviceName UTF8String]), 0);
nit deviceName.UTF8String

[the sun, 2016-03-04 07:46:58]

On 2016/03/04 01:18:35, tkchin_webrtc wrote:
> lgtm
> 
> I don't know anything about conductor.cc (not even what it does) - can you
check
> the git log and see who owns it?
> 
>
https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
> File talk/app/webrtc/objc/RTCVideoCapturer.mm (left):
> 
>
https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
> talk/app/webrtc/objc/RTCVideoCapturer.mm:41: +
> (RTCVideoCapturer*)capturerWithDeviceName:(NSString*)deviceName {
> On 2016/03/03 20:00:13, the sun wrote:
> > On 2016/03/02 21:13:37, tkchin_webrtc wrote:
> > > What is the new way of getting the cricket video capturer associated with
a
> > > device name?
> > > Should not eliminate this code, but provide the new pathway first.
> (Otherwise
> > > this class essentially becomes unusable; some third party folks might
still
> be
> > > using this)
> > 
> > I'm now using WebRtcVideoDeviceCapturerFactory to directly create the
capturer
> > (from device name).
> > 
> > Problem is, there does not appear to be any tests running the code. How do
we
> > make sure it works? Is it worth writing up a test for just this part of the
> > "legacy API"?
> 
> Nah, not worth adding a test for this. I've patched your CL and verified that
it
> works, thank you for adding it.
> 
>
https://codereview.webrtc.org/1715883002/diff/220001/talk/app/webrtc/objc/RTC...
> File talk/app/webrtc/objc/RTCVideoCapturer.mm (right):
> 
>
https://codereview.webrtc.org/1715883002/diff/220001/talk/app/webrtc/objc/RTC...
> talk/app/webrtc/objc/RTCVideoCapturer.mm:43: cricket::Device
> device(std::string([deviceName UTF8String]), 0);
> nit deviceName.UTF8String

It turns out you are one of the OWNERs of conductor.cc. :) I'm adding glaznev@,
the other owner, for input.

The code has not been touched (except for cross-code base maintenance) since the
move to git in August last year.

[the sun, 2016-03-04 07:48:14]

solenberg@webrtc.org changed reviewers:
+ glaznev@webrtc.org

[the sun, 2016-03-04 07:48:16]

Adding glaznev@, to verify the change to
webrtc/examples/peerconnection/client/conductor.cc

https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
File talk/app/webrtc/objc/RTCVideoCapturer.mm (left):

https://codereview.webrtc.org/1715883002/diff/200001/talk/app/webrtc/objc/RTC...
talk/app/webrtc/objc/RTCVideoCapturer.mm:41: +
(RTCVideoCapturer*)capturerWithDeviceName:(NSString*)deviceName {
On 2016/03/04 01:18:35, tkchin_webrtc wrote:
> On 2016/03/03 20:00:13, the sun wrote:
> > On 2016/03/02 21:13:37, tkchin_webrtc wrote:
> > > What is the new way of getting the cricket video capturer associated with
a
> > > device name?
> > > Should not eliminate this code, but provide the new pathway first.
> (Otherwise
> > > this class essentially becomes unusable; some third party folks might
still
> be
> > > using this)
> > 
> > I'm now using WebRtcVideoDeviceCapturerFactory to directly create the
capturer
> > (from device name).
> > 
> > Problem is, there does not appear to be any tests running the code. How do
we
> > make sure it works? Is it worth writing up a test for just this part of the
> > "legacy API"?
> 
> Nah, not worth adding a test for this. I've patched your CL and verified that
it
> works, thank you for adding it.

Thank you!

https://codereview.webrtc.org/1715883002/diff/220001/talk/app/webrtc/objc/RTC...
File talk/app/webrtc/objc/RTCVideoCapturer.mm (right):

https://codereview.webrtc.org/1715883002/diff/220001/talk/app/webrtc/objc/RTC...
talk/app/webrtc/objc/RTCVideoCapturer.mm:43: cricket::Device
device(std::string([deviceName UTF8String]), 0);
On 2016/03/04 01:18:35, tkchin_webrtc wrote:
> nit deviceName.UTF8String

Done.

[AlexG, 2016-03-04 20:02:12]

On 2016/03/04 07:48:16, the sun wrote:
> Adding glaznev@, to verify the change to
> webrtc/examples/peerconnection/client/conductor.cc
> 
Sorry, I am not familiar with this part of the code

[AlexG, 2016-03-04 20:02:25]

glaznev@webrtc.org changed reviewers:
- glaznev@webrtc.org

[the sun, 2016-03-04 20:34:23]

The CQ bit was checked by solenberg@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-04 20:34:35]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1715883002/260001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1715883002/260001

[the sun, 2016-03-04 20:55:05]

On 2016/03/04 20:02:12, AlexG wrote:
> On 2016/03/04 07:48:16, the sun wrote:
> > Adding glaznev@, to verify the change to
> > webrtc/examples/peerconnection/client/conductor.cc
> > 
> Sorry, I am not familiar with this part of the code

Ok, then I'm going to commit this CL and file a bug that we should either find
someone to take on this piece of code, or remove it.

[commit-bot: I haz the power, 2016-03-04 22:35:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-04 22:35:15]

Dry run: Try jobs failed on following builders:
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  win_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[tommi, 2016-03-05 07:51:57]

On 2016/03/04 22:35:15, commit-bot: I haz the power wrote:
> Dry run: Try jobs failed on following builders:
>   android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
>   linux_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
>   win_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

Is there no way to keep the sample working? It's one of our most relied upon
samples.

[the sun, 2016-03-05 08:43:29]

On 2016/03/05 07:51:57, tommi-webrtc wrote:
> On 2016/03/04 22:35:15, commit-bot: I haz the power wrote:
> > Dry run: Try jobs failed on following builders:
> >   android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
> >   linux_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
> >   win_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
> 
> Is there no way to keep the sample working? It's one of our most relied upon
> samples.

Shouldn't be a problem (except I need to convince someone with a Windows box to
help me test it it).

Looks like we could either use webrtc::VideoCaptureFactory::CreateDeviceInfo()
directly in Conductor::OpenVideoCaptureDevice() to enumerate devices, or add
another Init() method on cricket::WebRtcVideoCapturer which tries devices in
order and picks the first one which works (just like the Conductor method used
to do). Let me know if there is a particular way you'd prefer.

[the sun, 2016-03-07 22:18:01]

The CQ bit was checked by solenberg@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-07 22:18:07]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1715883002/300001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1715883002/300001

[the sun, 2016-03-07 22:18:17]

solenberg@webrtc.org changed reviewers:
+ tommi@webrtc.org

[the sun, 2016-03-07 22:18:51]

On 2016/03/07 22:18:07, commit-bot: I haz the power wrote:
> Dry run: CQ is trying da patch. Follow status at
>  https://chromium-cq-status.appspot.com/patch-status/1715883002/300001
> View timeline at
>  https://chromium-cq-status.appspot.com/patch-timeline/1715883002/300001

Adding tommi@ for conductor.cc and test run on Windows.

[commit-bot: I haz the power, 2016-03-08 00:24:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-08 00:24:19]

Dry run: This issue passed the CQ dry run.

[the sun, 2016-03-10 20:11:07]

solenberg@webrtc.org changed reviewers:
- tommi@webrtc.org

[the sun, 2016-03-14 16:33:14]

The CQ bit was checked by solenberg@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-14 16:33:22]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1715883002/340001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1715883002/340001

[commit-bot: I haz the power, 2016-03-14 18:58:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-14 18:58:03]

Dry run: This issue passed the CQ dry run.

[the sun, 2016-03-14 20:05:37]

On 2016/03/14 18:58:03, commit-bot: I haz the power wrote:
> Dry run: This issue passed the CQ dry run.

I have tested peerconnection_server and peerconnection_client locally on my
Linux machine and can verify that the code to setup video capturer works.

tommi@, can you verify that the patch works on Windows too?

[the sun, 2016-03-14 20:05:55]

solenberg@webrtc.org changed reviewers:
+ tommi@webrtc.org

[the sun, 2016-03-16 11:13:57]

solenberg@webrtc.org changed reviewers:
- tommi@webrtc.org

[the sun, 2016-03-16 11:14:46]

On 2016/03/14 20:05:37, the sun wrote:
> On 2016/03/14 18:58:03, commit-bot: I haz the power wrote:
> > Dry run: This issue passed the CQ dry run.
> 
> I have tested peerconnection_server and peerconnection_client locally on my
> Linux machine and can verify that the code to setup video capturer works.
> 
> tommi@, can you verify that the patch works on Windows too?

sprang@ helped out testing on Windows.

[the sun, 2016-03-16 11:22:51]

The CQ bit was checked by solenberg@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-16 11:22:59]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1715883002/360001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1715883002/360001

[sprang_webrtc, 2016-03-16 12:52:21]

On 2016/03/16 11:22:59, commit-bot: I haz the power wrote:
> Dry run: CQ is trying da patch. Follow status at
>  https://chromium-cq-status.appspot.com/patch-status/1715883002/360001
> View timeline at
>  https://chromium-cq-status.appspot.com/patch-timeline/1715883002/360001

I manually tested this on Windows, using peerconnection_server and
peerconnection_client samples. Seems to work fine.

[commit-bot: I haz the power, 2016-03-16 13:41:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-16 13:41:33]

Dry run: This issue passed the CQ dry run.

[the sun, 2016-03-16 14:12:14]

On 2016/03/16 12:52:21, språng wrote:
> On 2016/03/16 11:22:59, commit-bot: I haz the power wrote:
> > Dry run: CQ is trying da patch. Follow status at
> >  https://chromium-cq-status.appspot.com/patch-status/1715883002/360001
> > View timeline at
> >  https://chromium-cq-status.appspot.com/patch-timeline/1715883002/360001
> 
> I manually tested this on Windows, using peerconnection_server and
> peerconnection_client samples. Seems to work fine.

Thanks so much for the help Erik!

[the sun, 2016-03-16 14:12:23]

The CQ bit was checked by solenberg@webrtc.org

[the sun, 2016-03-16 14:12:24]

The patchset sent to the CQ was uploaded after l-g-t-m from
kjellander@webrtc.org, pthatcher@webrtc.org, tkchin@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1715883002/#ps380001 (title:
"rebase")

[commit-bot: I haz the power, 2016-03-16 14:12:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1715883002/380001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1715883002/380001

[tommi, 2016-03-16 15:51:43]

On 2016/03/16 14:12:14, the sun wrote:
> On 2016/03/16 12:52:21, språng wrote:
> > On 2016/03/16 11:22:59, commit-bot: I haz the power wrote:
> > > Dry run: CQ is trying da patch. Follow status at
> > >  https://chromium-cq-status.appspot.com/patch-status/1715883002/360001
> > > View timeline at
> > >  https://chromium-cq-status.appspot.com/patch-timeline/1715883002/360001
> > 
> > I manually tested this on Windows, using peerconnection_server and
> > peerconnection_client samples. Seems to work fine.
> 
> Thanks so much for the help Erik!

Thanks Erik and sorry for the delays Fredrik :/

[commit-bot: I haz the power, 2016-03-16 16:35:00]

Description was changed from

==========
Remove DeviceManager and DeviceInfo.

BUG=webrtc:5615, webrtc:5620
==========

to

==========
Remove DeviceManager and DeviceInfo.

BUG=webrtc:5615, webrtc:5620
==========

[commit-bot: I haz the power, 2016-03-16 16:35:03]

Committed patchset #20 (id:380001)

[commit-bot: I haz the power, 2016-03-16 16:35:12]

Description was changed from

==========
Remove DeviceManager and DeviceInfo.

BUG=webrtc:5615, webrtc:5620
==========

to

==========
Remove DeviceManager and DeviceInfo.

BUG=webrtc:5615, webrtc:5620

Committed: https://crrev.com/8ad582d83ffb935ba06b2474d1ec1ff3650ac376
Cr-Commit-Position: refs/heads/master@{#12020}
==========

[commit-bot: I haz the power, 2016-03-16 16:35:14]

Patchset 20 (id:??) landed as
https://crrev.com/8ad582d83ffb935ba06b2474d1ec1ff3650ac376
Cr-Commit-Position: refs/heads/master@{#12020}