- Status update on prototype
- Real-time communication channel
- Mailing list
- Next meeting
- AutomatedTester, ochameau, yulia, sole, 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.
- I agree.
- 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?
- 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.
- I agree, but how confident are you that this code you’re working on will be ready for central?
- The good news is that it doesn’t require any architectual work.
- It implements parts of the
Targetdomain for attaching automatically to targets.
- 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?
- 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.
- 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.
- It largely depends on how quickly we can get a review from the build peers.
- As ted suggested, the patch itself will ship with
- But we still need
r+on the parts the interlink with the build system.
- Then if I help out to get the build peers’ attention, we can land it by Wednesday?
- 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.
- I would prefer not using IRC because of the spam.
- 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.
- Could we use the DevTools Slack?
- Yes, the only problem is it’s not archived because it’s not a paid instance of Slack.
- Can we have an invite-only channel on IRC?
- 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.
- 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.
- Do we worry about the channel being indexed?
- I don’t think so.
- People are already watching other channels for notifications, such as for bugs being fixed.
- Do you have an opinion, Alex?
- We’re all on IRC, so that seems like a reasonable option.
- 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.
- There was also an intent-to-implement document.
- What is the status of that? When are we sending it out?
- 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.
- 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.
- ochameau away Friday 8 March
- ystartsev away Monday 18 March – 12 April