WebDriver/RemoteProtocol/Meetings/2019/03/04: Difference between revisions
< WebDriver | RemoteProtocol | Meetings
Jump to navigation
Jump to search
(Created page with "== Agenda == * Real-time communication channel ** Slack/IRC? == Roster == ; Present : … ; Regrets : … == Minutes == == PTO (🌷) == * ato away Tuesday 5 March * och...") |
(add minutes) |
||
Line 1: | Line 1: | ||
== Agenda == | == Agenda == | ||
* Status update on prototype | |||
* Real-time communication channel | * Real-time communication channel | ||
** Slack/IRC? | ** Slack/IRC? | ||
* Mailing list | |||
* Intent-to-implement | |||
* Next meeting | |||
== Roster == | == Roster == | ||
; Present | ; Present | ||
: | : AutomatedTester, ochameau, yulia, sole, ato | ||
; Regrets | ; Regrets | ||
== Minutes == | == 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 | |||
: HYour 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 | |||
: Yes, we were obviously derailed by some politics last week. | |||
: 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 reasonable. | |||
: 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? | |||
; 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 (🌷) == | == PTO (🌷) == |
Revision as of 11:35, 4 March 2019
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
Target
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
- HYour 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
- Yes, we were obviously derailed by some politics last week.
- It largely depends on how quickly we can get a review from the build peers.
- As ted suggested, the patch itself will ship with
r=ochameau,ato
. - But we still need
r+
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 reasonable.
- 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?
- 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