add notes for tooling team 27th Jan

st-embroider/2024/2026-01-27.md

@@ -0,0 +1,59 @@
+# YYYY-MM-DD
+
+Note Taker: 
+Time Keeper: 
+
+## Attendees
+
+Add yourself to the list if you attend and check the box!
+
+- [x] Ed Faulkner (EF)
+- [x] Chris Manson (CM)
+- [x] Alex (A)
+- [x] Preston Sego (PS)
+- [x] Simon Ihmig (SI)
+- [x] Katie Gengler (KG)
+- [ ] Krystan HuffMenne (KH)
+- [x] Peter Wagenet (PW)
+- [ ] James Davis (JD)
+- [x] Liam Potter (LP)
+- [x] tommyjr
+
+## Topics
+
+### Ember 7 pre-planning: deprecation removals (not covered by the auto throw e.g. AMD bundles and barrel file), breaking bugfixes (flipping default values in Ember ENV), etc. <@mansona>
+
+- Ones that we know of
+  - Making sure we don't publish AMD bundles
+  - Making sure we don't publish the barrel file
+- it's great that we have the throw on deprecation functionality but we should endevour to remove as much as possible
+- flipping default values in Ember ENV
+  - this should have been done at an earlier major
+- KG: can we break the `ember-testing` package
+  - we only soft deprecated it
+  - I can't make it work on a modern ember
+  - CM: can we clarify what you are talking about - because we have it in the new bluerpint
+  - KG: it has some side-effects but there are some other helpers (that aren't moved to `@ember/test-helpers`)
+  - we contemplated adding a deprecation and backporting it
+  - EF: we need to make sure that the last few things that are used in `@ember/test-helpers` are structured well
+
+#### The classic app blueprint was not updated to use warpdrive when the Vite one was. What is our policy here? Do we need to do a release backport? (seems risky) Should we do a beta backport? Should we (as a team) make sure that we don’t merge large structural changes to the vite blueprint without there also being one for the classic? <@mansona>
+
+- (explanation of the situation)
+- EF: do we expect it to work - yes
+- CM: do we do a backport a "fix" to the release
+- EF: i agree the this is a policy question - it would have been better if we did this at the same time
+- we could decide to just fix it with the release pipeline
+- CM: but that would mean the cognitive disonance would exist for 2 minors
+- (discussion about deprecations)
+- CM: I want to deprecate the old blueprint (and potentially the old build) during the 7.x cycle
+- EF: then keeping the new blueprint and the classic one up to date helpes people cross the gap
+- CM: then we don't need it to be backported to release - but we can backport to beta if we want to
+
+
+### isBinaryFile situation - do we downgrade? Maybe we vendor the code? https://github.com/gjtorikian/isBinaryFile/pull/102 <@mansona>
+
+- EF: this response from the maintainer doens't instill confidence
+- CM: 🫠
+- EF: why are we even using this dependency? 
+- CM: we can just downgrade the package