WebDriver/RemoteProtocol/Meetings/2020/01/10: Difference between revisions

WebDriver/RemoteProtocol/Meetings/2020/01/10 (view source)

Revision as of 15:43, 10 January 2020

5,008 bytes added , 10 January 2020

minutes

Ato

715

edits

@@ Line 1: / Line 1: @@
 == Agenda ==
 * Beta project update (''mmucci'')
-* Backlog Process Review (''mmucci'')
+* Backlog process review (''mmucci'')
+* Strategy of deprecating puppeteer-firefox (“Juggler”)
+== Roster ==
+; Present
+; Regrets
+== Minutes ==
+=== Beta project update ===
+Total MVP scope is 70, so far 30% completion. Seven bugs in developemnt, 30 in backlog. Completion rate is nine bugs per milestone. Early forecast completion date is currently 9th April.
+We’ve finished M1 with 21 bugs out of the six required. Completion rate was 7.0 at the beginning of the project, but it has now increased to 9.0. This consequently means the minimum milestone throughput has been reduced to 5.0, which takes some load off.
+==== Comments ====
+; AutomatedTester
+: We thought this would happen because we put a lot of contingency in.
+=== Backlog process review ===
 ** '''MVP Bugs'''
 *** ''In Development''
@@ Line 29: / Line 52: @@
 ** If no contingency is available an existing MVP bug will be swapped out to account for the new MVP bug.
-* Strategy of deprecating puppeteer-firefox (juggler) necessary because download numbers spiked a lot recently
+What happens when you put a bug in the reserve backlog? It means it's important, but we're not committing to completing it. If you work on a reserve bug, it gets moved into the MVP because it is what we—as a team—right now think it is most important thing to work on.
+; whimboo
+: We have chosen the MVP bugs at the beginning of the milestone. This means we might risk losing out on some previously-prioritised MVP bugs.
+; mmucci
+: Yes, there’s a risk of that. But it means we accurately reflect what we are working on.
+; AutomatedTester
+: Logging, for example, makes everyone’s life easier.
+: But having a sense of what is important is the key here. Not everything is equally important, so the initial MVP bug selection was the “optimal”.
+; ato
+: Several categories: improving everyone's lives; important unplanned work that turns out (permafailure on a beta simulation, for ex.); using time wisely while you are blocked
+; maja_zf
+: Work that is easy to do while avoiding a context switch
+; ato
+: Spreadsheet helps with seeing big picture and accountability
+; AutomatedTester
+: [[Remote/Milestones#High_Priority_Subset]]
+; maja_zf
+: This is a tool that is supposed to help us by triggering discussion about priorities. I’m cautious that the tool should not get in the way.
+: If we think something is important, we should just work on it.
+: What I’m hearing is that everything eventually gets worked on.
+; AutomatedTester
+: It comes down to what it is high priority and what is not.
+: This is “nice to have”, maybe consider dropping it into the backlog.
+: But if something comes up, we may have to swap something out.
+; whimboo
+: I’m under pressure to do some work on the JsWindowActor stuff before the all-hands.
+: I am also trying to finishing up the device emulation, but it’s going to take more time.
+; AutomatedTester
+: Fission unlocks other things, so I would say returning the device metric emulation to the list.
+; whimboo
+: The issue is that the device metrics emulation blocks a lot of tests.
+; AutomatedTester
+: We can ignore the failing tests. People will look that it works, but not be so interested in the pass rate.
+=== Strategy of deprecating puppeteer-firefox (“Juggler”) ===
+Necessary because download numbers spiked a lot recently.
 ** https://www.npmjs.com/package/puppeteer-firefox
 ** Remaining issue list: https://github.com/puppeteer/puppeteer/issues?q=is%3Aissue+is%3Aopen+firefox+label%3Afirefox
-== Roster ==
+The download rate for puppeteer-firefox (Juggler) has spiked. People are now aware that Puppeteer works with Firefox, but they are mislead by the npm package.
+The question is, what should be done?
+Mininum: download Firefox Nightly, integrate test-skips into upstream, deprecation message in puppeteer-firefox npm package.
+'''ACTION for AutomatedTester:''' Arrange meeting with Mathias to discuss Juggler deprecation.
+Some open issues in the Puppeteer issue tracker are related to Juggler, and should be closed. But what is our story?
+Can close the Juggler issues stating that it’s nolonger maintainer, new version available later this year.
+We are ready to get early feedback from early adopters.
-; Present
+An aside about building on all release channels:
-; Regrets
-== Minutes ==
+; ato
+: I don't think we can avoid early adopters trying out our implementation…
+: Follow-up question: what is priority of making it easier to use Puppeteer with Firefox?
+; AutomatedTester
+: Puppeteer with Chromium downloads a Chromium version kind of opaquely to the user, no backwards compat.
+; maja_zf
+: For now we can get away with having Puppeteer always download the latest Nightly.
+; ato
+: Supporting all the release channels will take six months of preparation, due the patches having to ridee the trains.
+; AutomatedTester
+: Just Nightly for now is OK.  Later we can work with Mathias to plan Puppeteer releases with regard to supporting other release channels.
+; ato
+: Clarification: building Firefox versus shipping Firefox.
+: We’re not building the remote agent as part of the release branch so emergency work can come up.
+: No need to ship anywhere except Nightly.
+; AutomatedTester
+: Will talking with sheriffs help?
+; ato
+: I guess we know if the problem happens again, on the next beta simulation, we know we should consider fixing it by preparing to build on all branches.
+: The core issue is more an annoyance than a problem: we had to disable the TaskCluster job because the browser-chrome harness dislikes having empty test manifests.
+: In conclusion, this is not a huge problem and we can deal with it when/if it happens again.
 == Recording ==
+None this week due to technical difficulties.
 == Progress ==