Agenda
- Introductions
- Bindings team purpose and proposal
- Introspection next steps
- Planning
Attendance
Attendees: ebassi, amolenaar, creiter, bugaev, mtiede, jan-willem, danyeaw
Regrets: slomo, bilelmussaui, ptomato
Actions
Minutes
- Round of introductions
- Bindings team purpose and proposal (ebassi)
- part of the technical governance proposal outlined at GUADEC 2025
- originally, the bindings were supposed to be a special interest group of the platform team, but after various discussion, it was preferable to have a proper high level team, especially if teams are going to be represented in a future Steering Committee
- the bindings team is meant to be a reference point for planning across projects; questions from library developers for support and idiomatic use of new features; documentation; and release notes
- the team will have its own space on GitLab, Matrix, and Discourse
- regular meetings, either on video calls or simple chat, at regular intervals; meetings don’t need to be held often
- the meeting agenda is composed of issues that are labelled with a “bindings team” label on GitLab, and can be proposed by everyone
- the label will also be used to track issues that are relevant for the GNOME release notes, or things that require additional/special QA from the release team
- amolenaar: it’s hard to decide what’s relevant and what isn’t; we’ll figure it out on the way
- ebassi: yes; as a rule of thumb, if it’s an internal change that is well-covered by the test suite it may be omitted; we’ll definitely have to figure it out over time
- ACTION: ebassi: Schedule the next meeting
- mtiede: since gir.core is not part of GNOME, what’s the role of bindings like mine?
- ebassi: the team is open to all bindings that provide access to GNOME, does not matter if they are hosted elsewhere; the Rust bindings are on github, and they are part of Circle. You should consider getting gir.core in Circle as well.
- Introspection next steps (ebassi)
- During the GTK hackfest I started the effort to move g-ir-scanner into GLib; still in progress, with additional help from Florian (GTK/Android dev) and bugaevc
- Lots of details still up in the air
- Should help cross-compilation, and remove the circular dependency between GLib and gobject-introspection
- Blocks additional changes to g-ir-scanner, like reducing the dependency on generating/compiling/running GType query code at build time
- Vala status (ebassi)
- Issue of maintainability was raised on Discourse
- bugaevc: still no answer from ricotz; don’t really want to become the next single point of failure; not enough people are willing to set up a shared maintenance role
- ebassi: may be worth reaching out to the release-team, at this point