B2G emulator does not seem to use eth0. Ex: If you want to run any amount of testing that reaches out to the web the B2G emulator doesn't seem to browse the web. I believe what has happened is that we have a hard dependency on wifi needing to be connected. Which for web testing purposes makes the emulator fairly useless.

The downside here is that testing would only be able to occur on the actual device vs on the emulator. I tested this on the B2G Daily Emulator Build: 10/02/2012 I am running on Ubuntu 11.10, running in a virtual machine.

Is this a regression? Does it block automation?

This generally will block any use of the emulator for testing web content. It does not block automation, as all automation runs against localhost. This is a regression, because this used to work in the past. I don't know how many people are still using the emulator as a test environment because most people have access to the otoro, so possibly the emulator has been deprioritized

David, do you have an otoro?

Yes, but the emulator is the test environment. Ideally we would need to reproduce errors in the test environment, as it gives a non device specific accounting of the problem.

Re-nomming for discussion today.

Let's get this fixed (blocking community members and also near future tinderbox tests). It's likely the same fix as was used in bug 793213.

I believe the phone will be shipped even if this is not fixed.

(In reply to Vivien Nicolas (:vingtetun) from comment #8) > I believe the phone will be shipped even if this is not fixed. Should we renom?

Vivien, I think it makes sense for someone who would be familiar with this part of the platform to be on this bug. If it is a 2 hr fix vs a 2 week fix really is what makes the difference in this case. And it does help me debug. The question is not whether we will ship the device with or without this working. The question is how many hours does it save devs by helping me more closely identify a problem, and how many community members does it enable if we have community members using the emulator vs not. Whether we ship the phone with / without this fixed is in my opinion not the right question.

(In reply to dclarke@mozilla.com [:onecyrenus] from comment #10) > Vivien, > I think it makes sense for someone who would be familiar with this part of > the platform to be on this bug. > If it is a 2 hr fix vs a 2 week fix really is what makes the difference in > this case. And it does help me debug. > The question is not whether we will ship the device with or without this > working. > The question is how many hours does it save devs by helping me more closely > identify a problem, and how many community members does it enable if we have > community members using the emulator vs not. > Whether we ship the phone with / without this fixed is in my opinion not > the right question. As far as I've understood this is the main meaning of the blocking-basecamp flag.

(In reply to Vivien Nicolas (:vingtetun) from comment #11) > (In reply to dclarke@mozilla.com [:onecyrenus] from comment #10) > > Vivien, > > I think it makes sense for someone who would be familiar with this part of > > the platform to be on this bug. > > If it is a 2 hr fix vs a 2 week fix really is what makes the difference in > > this case. And it does help me debug. > > The question is not whether we will ship the device with or without this > > working. > > The question is how many hours does it save devs by helping me more closely > > identify a problem, and how many community members does it enable if we have > > community members using the emulator vs not. > > Whether we ship the phone with / without this fixed is in my opinion not > > the right question. > > As far as I've understood this is the main meaning of the blocking-basecamp > flag. I entirely agree with Vivien's comments, although I do understand what I think David is describing. He's probably talking more about time to complete the fix along with the benefit of improved debugging. However - the reality is that we can't fix everything for v1. In the context of the QA team, many of us don't use the emulator to do the style of debugging described. And I do think the phone will ship with this not working. Renoming to minus.

While it'd be great to keep the emulator working, we can't hold the release for it :(

(In reply to dclarke@mozilla.com [:onecyrenus] from comment #0) > B2G emulator does not seem to use eth0. But actually we should remove eth0 from B2G emulator because there is no such device on a phone. We should, however, create emulated rmnet<N> devices, and probably wifi as well. Developers in Taiwan RIL/Network team have been discussing this issue for a while. We're mostly going to implement rmnet first because it seems to be much much more easier than wifi.

This bug can be solved with bug 871475.