Merge pull request #55 from nodejs/add-minutes-for-meeting-Oct-31-2022

Add minutes for meeting Oct 31 2022

Author: RaisinTen

README.md

@@ -29,3 +29,4 @@ Meeting Notes
 
 - [2022-09-05](./meetings/2022-09-05.md)
 - [2022-10-01](./meetings/2022-10-01.md) (OpenJS Foundation Collaborator Summit: Dublin)
+- [2022-10-31](./meetings/2022-10-31.md)

meetings/2022-10-31.md

@@ -0,0 +1,142 @@
+# Node.js Single-Executable Meeting 2022-09-05
+
+## Links
+
+* **Recording**: https://youtu.be/Lw3cyjUofI4
+* **GitHub Issue**: https://github.com/nodejs/single-executable/issues/54
+
+## Present
+
+* Claudio Wunder @ovflowd
+* Darshan Sen @RaisinTen
+* Juan Cruz Viotti @jviotti
+* Michael Dawson @mhdawson
+* Richard Lau @richardlau
+* Tony Gorez @tony-go
+
+## Agenda
+
+* Inclusion of postject in the Node.js binary
+  * Exposing segment names to the public API
+    * Darshan: If we don't include Postject into Node.js, the name of the
+      segment becomes a part of the interface, so changes to that will be
+      semver-major. Hiding that behind something like `node --compile` will
+      prevent that.
+    * Michael: We want to support more than just one way of doing it, so that if
+      anyone wants to inject the data in a different way, then can.
+
+  * Single section or multiple sections
+    * Darshan: Do want everything to be packed into a single section?
+    * Juan: There might be a maximum size limit on the amount of data that can
+      be loaded which might be too restrictive.
+    * Michael: Most generic solution is if Postject finds you a list of sections
+      that we were trying to load and give you the pointers to all of those.
+    * Darshan: Another point is that, if we want everything to be in a single
+      section, it would require users to pack everything into a specific format.
+
+  * Michael: Key things to consider:
+    * It might make the binary bigger.
+    * We can make it non-invasive enough that people who aren't using it don't
+      get affected.
+    * Distros don't like big blobs of things that they do not know what's in
+      there, so that's problematic for WASM.
+    * Since we have a separate project, we have more flexibility, specially in
+      the early stages.
+  * Darshan: About the size and WASM part, we are trying to get rid of LIEF, so
+    that way, we don't have to worry about the WASM part and the code size too
+    will go down significantly.
+  * Juan: There are 2 keys parts of Postject - the writing part and the reading
+    part. Which one are we talking about including in Node.js core?
+  * Michael: The reading part is not that big, so including that sounds
+    reasonable.
+
+  * Testing
+    * Darshan: It's not possible to test the creation of Single Executable
+      Applications on CI if we keep Postject outside Node.js because using
+      Postject would require outbound requests, so we would need to place such a
+      test in `test/internet` but that doesn't run on CI.
+    * Richard: It should be possible to build Node.js without an internet
+      connection if you have the source files locally. There are some caveats,
+      like you can't do doc testing because that requires the installation of
+      modules.
+    * Juan: Maybe we can use `objcopy` as suggested in
+      https://github.com/nodejs/postject/issues/63 just for CI? However, a
+      downside is that it won't let us create PE files on Linux or macOS.
+    * Darshan: We could probably do that but it would feel like dropping support
+      for creating binaries for other platforms on a different platform, which
+      pkg supports currently.
+    * Darshan: Another problem is that while `objcopy` is present by default on
+      Linux it needs to be downloaded on macOS using `brew install llvm`.
+    * Richard: We don't install llvm anywhere, just Xcode on macOS. If something
+      from llvm conflicts with something from Xcode, it might be problematic.
+    * Claudio: What about Windows?
+    * Michael: How big is Postject?
+    * Darshan: 4MB.
+    * Michael: Maybe we could include Postject in the test? That way, it could
+      be used for testing but not necessarily be a part of the Node.js binary.
+
+  * Inclusion of the injection part in Node.js after size reduction
+    * Juan: Darshan is working on getting rid of LIEF and writing the injection
+      part on only one platform in plain JS. If we accomplish that, it's going
+      to significantly reduce the size. Would that change something?
+    * Michael: The injection part doesn't necessarily have to be a part of core
+      but the reading part does. Having the injection part in core is more about
+      ergonomics.
+    * Darshan: A reason why the injection part shouldn't be a part of Node.js
+      core is that if we run `node --compile` on macOS, it's gonna be a Mach-O
+      binary, so creating a PE executable would require sending outbound
+      requests to download that from somewhere, which we don't want to do.
+    * Juan: How common is that?
+    * Michael: You probably want to do it for multiple platforms.
+    * Juan: Even if you generate all of them on Linux, you might want jobs
+      actually testing the CLI, on multiple platforms, so why not just run pkg
+      on all platforms?
+    * Darshan: Might not always be the case because if we consider macOS ARM64,
+      that's very rare to find, so in most cases you'll build the binary but not
+      test it on CI.
+
+  * Inclusion of project license and version info
+    * Darshan: Should we include the LIEF license in Node.js if we are only using
+      the reading part of Postject, just because it's a part of the Postject
+      license?
+    * Juan, Michael: No.
+    * Michael: We should also add a maintaining-postject document, for
+      instructions on upgrading, etc.
+    * Juan: Should we also include the version in `process.versions`?
+    * Darshan: There are several dependencies that don't show up in
+      `process.versions`, like `undici`.
+    * Darshan: The fuse sentinel string is also a part of Postject, so do we
+      want Node.js to use a different string to keep things less tied?
+    * Michael: Maybe use a define for that?
+    * Michael: Long term, maybe we can make Postject a part of Node.js but for
+      now we can keep it as a separate project for more flexibility.
+
+  * Experimental warning
+    * Darshan: A point that Geoffrey raised is about emitting an experimental
+      warning. When should we do that - while compiling the SEA or while running
+      the SEA?
+    * Michael: Easiest thing is including for both but users can suppress these
+      warnings if they want.
+
+  * Option for users to opt out of having injectable Node.js binaries
+    * Michael: Let's also place even  the reading part behind a compile time flag,
+      so that users can opt out of having this feature if they want.
+    * Darshan: That can be done but how do we test both cases where this feature
+      is enabled / disabled?
+    * Michael: We can have separate jobs on Jenkins.
+
+  * Tony: If we decide to have the read part in Node.js core and the injection
+    side in Postject, does that reduce the scope of Postject?
+  * Michael: We would need the same functionality, so it doesn't change the
+    whole use case in anyway.
+
+### Announcements
+
+* Juan: Tony will start working as a co-maintainer of Postject and work on the
+  SEA initiative soon!
+
+## Upcoming Meetings
+
+* **Node.js Project Calendar**: <https://nodejs.org/calendar>
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.