WebDriver/RemoteProtocol/Meetings/2019/03/04: Difference between revisions

6,175 bytes added , 26 February 2021

m

Whimboo moved page Remote/Meetings/2019/03/04 to WebDriver/RemoteProtocol/Meetings/2019/03/04: Reorganization for WebDriver BiDi project documenation

Whimboo

canmove, Confirmed users, Bureaucrats and Sysops emeriti

4,714

edits

@@ Line 1: / Line 1: @@
 == Agenda ==
+* Status update on prototype
 * Real-time communication channel
 ** Slack/IRC?
+* Mailing list
+* Intent-to-implement
+* Next meeting
 == Roster ==
 ; Present
-: …
+: AutomatedTester, ochameau, yulia, sole, ato
 ; Regrets
-: …
 == Minutes ==
+=== Status update ===
+; ato
+: Let’s start with the positives.
+: I have been able to fix the worries we had with the HTTPD, and it can now serve WebSocket connections  off the same server.
+: It required some nasty hacks to repurpose the underlying socket connection, and I haven’t tested if it can support multiple connections yet, but it works reasonably well for now.
+: This means there are no show-stoppers left that we know about.
+: We originally listed deduplicating EventEmitter.jsm as a hard requirement for shipping this, but I’m starting to think we can file a bug and address this afterwards.
+; ochameau
+: I agree.
+; ato
+: We got slightly derailed last week, but we’re on track of landing the prototype in central this week.
+: One question, though: I know ochameau had some local code lying around he has not landed yet?
+; ocheameau
+: I’m trying to set us up so we can run Puppeteer with a simple, näive script.
+: Preliminary work on getting Puppeteer working without running any domain commands.
+: There are some small differences to what we’ve done so far, because they’re not using the npm package chrome-remote-interface we have been working against.
+: I was convinced they were using that, because nearly everyone—including VSCode—uses it.
+: I tried to figure out why they’re not using chrome-remote-interface, but I couldn’t find any good explanation.
+: Apparently Puppeteer doesn’t even clone the Chrome frontend client.
+: So this means they’ve written their own.
+: The only downside to this is that I thought we were going to be using chrome-remote-interface for writing the tests.
+: It’s an obvious choice because it runs in web content, which means we can run it as a browser-chrome test.
+: If we want to support Puppeteer well, the best way is to actually run the Puppeteer client and its tests on TaskCluster as a separate job, where we shell out to Node.js.
+; ato
+: I agree, but how confident are you that this code you’re working on will be ready for central?
+; ochameau
+: The good news is that it doesn’t require any architectual work.
+: It implements parts of the <code>Target</code> domain for attaching automatically to targets.
+; ato
+: Then it sounds like we made the right technical decisions regarding architecture when we started out, and I’m happy you didn’t have to go back and change it.
+: However, ''precisely'' because it builds on top of what we already have, does it make sense for us to punt this until after we’ve landed the initial prototype in central?
+; ochameau
+: Your patch to the HTTP is more important, otherwise we won’t be compatible with anything.
+: My work will make it possible for us to then connect to Puppeteer, but it won’t work without the HTTP fix.
+; AutomatedTester
+: If we defer your patch, what is the timeline for getting the code into the tree?
+: I know you said “by end of last week” before, but we obviously missed that.
+; ato
+: It largely depends on how quickly we can get a review from the build peers.
+: As ted suggested, the patch itself will ship with <code>r=ochameau,ato</code>.
+: But we still need <code>r+</code> on the parts the interlink with the build system.
+; AutomatedTester
+: Then if I help out to get the build peers’ attention, we can land it by Wednesday?
+; ato
+: I think that would be a reasonable estimate.
+: I will have the HTTP fix in by end of today.
+: Alex, it would be good if you could start the secondary cursory review now.
+=== Real-time communication ===
+; sole
+: I would prefer not using IRC because of the spam.
+; AutomatedTester
+: The one problem I see with Slack, is if we want to have a chat with Googlers, they can’t get onto Slack because of the NDA requirement.
+; yulia
+: Could we use the DevTools Slack?
+; sole
+: Yes, the only problem is it’s not archived because it’s not a paid instance of Slack.
+; yulia
+: Can we have an invite-only channel on IRC?
+; AutomatedTester
+: The way we have solved this on certain IRC channels, is by setting a special mode that makes it impossible for unregistered users to join them.
+: This effectively addresses the spam problem.
+; ato
+: Yes, infact there’s a special mode you can set that allows users to ''join'' a channel, but not speak until they register.
+: I think that makes more sense.
+; sole
+: Do we worry about the channel being indexed?
+; AutomatedTester
+: I don’t think so.
+: People are already watching other channels for notifications, such as for bugs being fixed.
+; ato
+: Do you have an opinion, Alex?
+; ochameau
+: We’re all on IRC, so that seems like a reasonable option.
+=== Mailing list ===
+; ato
+: I’m still struggling to get the dev-remote mailing list created.
+: No one in IT seems to want to take responsibility for it, and it keeps getting transferred between different people.
+: I reached out to cshields last week and he told me that Mozilla is decommissioning Mailman and the NNTP [newsgroups] connection, and instead moving to Google Groups.
+: I have personal reservations against Google Groups because they are basically impossible to join without already having a Google account.
+: But I want our mailing list to live alongside dev-platform and firefox-dev, so I’m proceeding with this option.
+: cshields also mentioned Discourse as a possible alternative if we didn’t want Google Groups.
+: But I have had problems using the Mozilla Discourse server, for various admin reasons.
+: Trying to work those out, so it may be an option in the future.
+=== Intent-to-implement ===
+; yulia
+: There was also an intent-to-implement document.
+: What is the status of that?  When are we sending it out?
+; ato
+: I think that largely depends on what comes out of our afternoon meeting.
+: But I would like to get it out by end of this week, or possibly early next week.
+=== Next meeting ===
+; ato
+: This meeting returns to its normal schedule next week.
+: The reason we did it one hour later today was that we have an afternoon meeting, and I didn’t want to spend eight hours at work.
+: So next week’s meeting will be coming Monday at 09:00 GMT/10:00 CET.
 == PTO (🌷) ==
-* ato away Tuesday 5 March
 * ochameau away Friday 8 March
 * ystartsev away Monday 18 March – 12 April

WebDriver/RemoteProtocol/Meetings/2019/03/04: Difference between revisions

WebDriver/RemoteProtocol/Meetings/2019/03/04 (view source)

Revision as of 20:09, 26 February 2021