Merge pull request #2 from nodejs/benjamingr-patch-1

Add meeting notes for first meeting

meetings/12-06-18.md

@@ -0,0 +1,203 @@
+# Node.js Promise Debugging Meeting 12-06-2018
+
+**GitHub Issue**:  https://github.com/nodejs/promise-use-cases/issues/28
+**Minutes Google Doc**: https://docs.google.com/document/d/1HHBLd_k2-sHMOj7DHgEzKcvYclX1BHQa95SIQYGILx0/edit
+
+## Present
+
+Benedikt Meurer (@bmeurer)
+Benjamin Gruenbaum (@benjamingr)
+Julien Gilli (@misterdjules)
+Peter Marton (@hekike)
+Ruben Bridgewater (@BridgeAR)
+Yunong Xiao (@yunong)
+Michael Dawson (@mhdawson) 
+
+## Agenda
+
+ - Introductions (10m)
+ - Presentation of the problem with postmortem debugging and promises (10m)
+ - How to proceed and gather use cases (10m)
+ - How to collaborate and on this (10m)
+
+
+## Minutes
+
+Introductions:
+Yunong - Node @ Netflix
+Julien - used to work at Joyent where was involved in Node.js, works at Netflix now
+Peter - used to work on an APM solution, now working at Netflix
+Benedikt - Node.js perf lead at V8
+Reuben - Node.js @ NearForm
+Benjamin - likes promises
+Michael -  Node.js core and diagnostics
+
+Presentation of the problem with postmortem debugging and promises: 
+
+Yunong - Netflix team building post mortem debugging tools which other teams will use - they need to debug issues and they use core dumps.
+Postmortem - not just core dumps, but core dumps are the most useful tool.
+Use llnode and mdb 
+Important to their adoption of Node. 
+Julien - promises and postmortem interact at netflix - they provide a platform for developers and need to make sure their developer experience is good. 
+
+With promises it is challenging to understand the semantics with regards to error handling and how it interacts with generating artifacts (core dumps or else).
+
+Want to be confident to tell developers to use async/await and promises. 
+
+Yunong - we all understand promises are a thing and want to provide developers a way to use promises. They are very impatient. 
+
+Julien - looking for a pragmatic solution from the OPs side
+
+Benjamin - promises make it hard to take core dumps and we can’t synchronously handle the errors. Currently core dumps are relied on.
+
+Julien - correct, and we should focus on the agenda. 
+
+Yunong - we should figure the collaboration model.
+
+Julien - historically there has been a lot of repos and issues and the knowledge is spread out. We should figure out a centralized place where we can go and make sure we have the up-to-date perspective from the Node.js and V8 project.
+
+Benjamin - agreed
+
+Benedikt - how about we put this on top of `promise-use-cases`
+
+Julien - Suggests a new separate repo to solve this.
+
+Benedikt - is it specifically about promise post mortem debugging or is this more general about post mortem?
+
+Julien - in this case it’s promises and postmortem.
+
+Yunong - vet with the diagnostics WG if we want a more general repo. There are specific things about debugging promises and async functions.
+
+Julien - if we broaden the topic it’s harder to collaborate on it.
+
+Yunong - create new repo like promise-postmortem-debugging
+
+Julien - when we say postmortem we don’t mean core dumps, we mean everything that is after the program terminated. We are open to using any other type of artifact. What’s important is the time and not the core-dump itself.
+
+Benjamin - we can reuse the repo if we want to focus not just on postmortem.
+
+Benedikt - from v8 side - you’re looking for ways to debug in the wild. This has to be as useful as possible in order to debug the core issue.
+
+Ruben - the implementation details might be interesting in the context - Ruben is almost done with implementation to throw on GC. There was some thing Benjamin brought up about throwing synchronously if no catch handler is attached.
+
+Yunong - should it be a different repo?
+
+Benedikt - I think it should be promise debugging and not just postmortem because the service may die. 
+
+Yunong - rename or create new repo.
+
+Benjamin - sure.
+
+Julien - promise-use-cases repo is a bit too general because it also discusses performance and testing and other stuff.
+
+Benedikt - we should not just frame it as postmortem - but it should be in general promises debugging because we care about the browsers and the web platform too.
+
+Yunong - agreed.
+
+Benjamin - should we have meetings?
+
+Julien - would prefer not to have biweekly meetings. Prefer to have a reference document. 
+
+Ruben - agree with Julien.
+
+Yunong - carve out a section in the diagnostics summit to discuss this. We should be more proactive.
+
+Julien - we are not too familiar with the browser use cases of the browser. We would be able to contribute from a non-browser perspective.
+
+Benedikt - almost no one is shipping async/await in native, we see different implementation since people transpile. We want to use Node.js to understand the web story.
+
+Julien - would love information about bluebird and debugging.
+
+Benjamin - I have a lot of information about how people are using bluebird.
+
+Yunong - would be useful to be in the same repo.
+Benjamin - Want to make sure we are held accountable and focused.
+
+Michael - It’s been easier in other teams to have meetings to gain momentum.
+
+Yunong - we want to make sure we’re holding ourselves accountable to making forward progress. In 3 weeks let’s make sure we’ll have a bunch of use cases, in 3 weeks there’s the diagnostics summit - meet in person and go through the work we want to do. Want to make sure we don’t wait for meetings for progress.
+
+Julien - want things to be as fluid as possible. Not having meetings would encourage people to reach out. Agree about roadmap and goals.
+
+Michael - happy to try anything. As long as stuff happens it doesn’t matter, it’s just that often we see things tail off. Sometimes when you have somebody new it’s an easier way to get them ramped up. Not pushing to have another meeting, has seen in the past in some interval it helps.
+
+Benjamin - Let’s agree to have another meeting if we stall in 3 weeks.
+
+Julien - are we OK with describing use cases in issues.
+
+Benjamin - works for me
+
+Benedikt - useful for us to have concrete use cases. Wants something they can execute and 
+
+Julien - GitHub repo to gather use cases and documents.
+
+Benjamin - do we want to also do terminology or a reference document?
+
+Julien - having a reference document about the current state and where you can find them.
+
+Yunong - we should have documentation/guide of the expected behavior in the Node.js runtime.
+
+Julien - that’s a possible outcome that we might like. I want to centralize an understanding of where we stand today. What would be the best way to communicate between us? Should we have slack?
+
+Benjamin - should we open slack?
+
+Michael & Ruben - slack work
+
+Benjamin - how do we deal with disagreements? Do we escalate?
+
+Yunong - I would like to avoid uncollaborative working environment. When things have to go to a vote then things have gone bad. It should be the last resort.
+Julien - this group is more for bouncing off ideas and discussing them. The Node.js project operates under a specific governance model. More of a support function.
+
+Benjamin - I don’t expect that many disagreements as we’ve had in the past
+
+Yunong - it’s OK to disagree about implementation and it’s fine. The entire group things a different way is helpful.
+
+Julien -  It’s fine if we gather feedback even if we disagree.
+
+Yunong - we should do an ad-hoc meeting face-to-face if we get frustrated.
+
+Michael - Things come along much harder in person. 
+
+Benjamin - we should discuss the actual implementation stuff after we do the repo.
+
+Yunong - Sounds good to me
+
+Michael - does it makes sense to publicize the repo to see if other people are interested?
+
+Yunong - we should be inclusive and promote.
+
+Michael - I can help with that
+
+Julien - we should be disciplined that the information in the repo is scoped towards debugging and post-mortem. We should redirect and guard our scope.
+
+Yunong - we should have a charter.
+
+Julien - we want to avoid confusion.
+
+Benjamin - should we have a goals statement?
+
+Julien & Yunong - sure
+
+Benedikt - should be in the readme.
+
+Benjamin - We should PR all the things and wait 72 hours for objections.
+
+Yunong - yes.
+
+Julien - we should use the Node.js process when it’s not process heavy and do that.
+
+
+
+
+## Action Items
+ - Create a new repository (/promises-debugging) to collaborate on this. (Benjamin)
+ - Write README for `promises-debugging` and collaborate on this. (Julien, will be a collaborative effort)
+ - Write goals as part of the README.
+ - Add process to the README. The 72 hours PR thing basically. 
+ - Folks should feel free to file issues for each use case (All)
+ - See where we are in 3 weeks and schedule a meeting if we don’t have enough progress. (Benjamin)
+ - Make a central document as a reference about the issue, what the status is, where we’re moving - first draft - Julien
+ - Open a slack. (Ruben)
+ - Publicize the repo after we’ve set up and are ready. (Michael, Benedikt)
+ - GitHub Team @nodejs/promises-debugging (Michael)
+ - Add MayaLekova there please