Hey everyone, as you may know, the Build & Packaging working group meets monthly, on the first Tuesday of the month. It initially was all done in Zoom meetings, but to make accessibility easier, the meetings have been shifted to asynchronous day-long discussions in slack threads on the EEF slack, back in December 2022.
As was made clear in a thread earlier this year, people don’t necessarily know what goes on in these meetings or that they even take place.
This is great, thanks @MononcQc. One observation I have (based on the minutes) is that there really are not many posts tagged “Erlang Ecosystem Foundation”. Perhaps instead of opening up the private areas, more activity could be conducted in public areas and tagged appropriately?
These are meetings between members so it sort of makes sense they are held between members and not just public threads. The goal is to pull a bunch of motivated maintainers and contributors together to synchronize work and bounce ideas. They happen on top of the public discussions and public threads, not instead of them
Are the forums with appropriate tagging not going to be sufficiently public nor appropriately tagged?
Our one discussion topic this month were a quick survey of OTP-27 readiness. Keep in mind that the meeting was held when only 27-rc1 was released and does not account for 27-rc2 yet:
Rebar3: appears to be all-good. There’s a warning in there that’s patched and will need a new release
Elixir mostly good, a few details to iron out
rebar3_hexdoc has had v0.2.22 released to cover OTP-27
erlef/setup-beam is now being tested for OTP 27, it’s released and no issues are reported
kerl/kerl has been adapted for OTP 27, but it’ll only be release when 27 is out (we need to use the latest, from the main branch, until then), the relevant change being it creating the docs for 27 locally (using ex_doc)
I’m forced to admit attendance is a bit down and topics discuss are shrinking; for a fourth month in a row we had 2 or fewer topics to discuss, and only 1 topic to discuss for 2 months in a row.
Anything the members of this forum would like to ask the WG for next week’s meeting?
I’m late on these, but still ahead of the next async meeting (which is next Tuesday, first Tuesday of May). For the time being, have the April 2 minutes—with more topics and participants than we’ve had in a while:
OTP 27-rc2 General Chat
quick discussion around the new strings syntax and maybe being on by default
tracing sessions looks interesting, but participants haven’t had time to try them yet
a question was asked wondering if we’d get access to murmurhash3 (which is the internal hash for which no public interface exists)
John says there’s too much work right now and revamping hashing has been put on hold
Missing releases were cut for erlware_commons and Relx
A new rebar3 release was cut accordingly, with a bunch of long-standing fixes.
Adding OTP 27-rc2 to nixpkgs
Barry (first presence in meeting) has managed to make it work
there were challenges around ex_doc builds
the PR was merged later in the month
Support for a deprecated doc attribute
Currently the attribute is disjoint, supported by the compiler for OTP-specific deprecations, handled with macros and by xref for the rest of uses
Making it project-level (so the compiler can warn for any project) is on John’s personal to-do list, but it is harder to do than it appears because of in-house build systems
José points out that the way it works in Elixir is that compilation is done first, then a pass is done to find deprecations and missing calls
EEP-59 doc will look for -deprecated attributes and put them in the docs chunk, but you can also do it directly with doc metadata with -doc(#{ deprecated => ~"Use foo/0 instead" }).
This seems to cover Bryan’s needs
A suggestion was made about relying on xref (or maybe dialyzer, or both) to warn about deprecated functions. Tools overlap a lot, and xref is fast.
there was some extra discussion about ex_doc handling as part of the PRs, but also around performance implications based on dependencies and Nix’s model.
should rebar3_ex_doc continue leveraging the edoc provider?
This is more of a question thread since Bryan had no time to dig on this. Lukas may know, but wasn’t around for this meeting (may be due to Swedish holidays?)
the estimate Radek has is that since we support 2 major versions, we can probably drop support in the next 2 major versions; nothing else needs to be done to keep supporting the old ones though
Edoc drop not expected before OTP-29
Hot code upgrades project funding
Based on the Dandelion project (described at My favorite Erlang Container), Alexandre Zenon submitted a proposal for EEF funding to make it easier to get more hot upgrade support in the community
The B&P WG is the best spot for it
Fred to propbably give the most support as the author of Dandelion Project
There is a requirement to support Elixir as much as possible
Radek mentions it would be good to get finish_loading/1 instructions in general for type analysis and code upgrades, but this is considered out of scope for this project
Form Factor: first version was a GitHub template; the idea is to turn it to a Github Action (GHA) to make it easier for people to integrate it
Focus on Testing: the first version focused on tests, static analysis, hot upgrade tests, release building; testing the hot upgrade is what makes most sense to focus on in the GHA
Use normal versions: the first version used smoothver, a toy versioning scheme Fred introduced for fun (to demonstrate the safety of an upgrade). This is impractical so it should support whatever versioning users currently have
Configuration must be provided for the “global” tests to be run by the GHA
Detection should be provided for Erlang vs. Elixir projects since they may run different commands and have different constraints
Testing utils should go to Hex to let users import them as deps
Fred redirected a lot of configuration needs around using test configuration material and profiles (in Rebar3) or Environments (in Mix)
There’s some discussion to be had regarding Common Test: it’s okay for Erlang folks, but may be an issue for Elixir devs?
concern voiced as there is a risk of placing this under the erlef org: we are not like the apache foundation where things go to be funded for ongoing development, and not everything under the org is actually funded at all.
this is something we have seen with setup-beam
Wojtek is also okay keeping the project under Hex as an umbrella
We’ll still create the repo under erlef, but wanted the concern to be recorded and voiced
. My suggestion was only to avoid changing the existing board set-up, but I’m happy with whatever works for you.