Dear Team, Toddy, Mathias, (cc'ed Ivan, Taffit) I would like to share a few updates and progress from MiniDebConf Winterthur!
Talk Announcement ================ I have a updated talk scheduled for tomorrow (Sunday) at 13:50 European Time: Modernizing Debian's Go Ecosystem: From 2011 Time-Travel to Module-Aware Builds You found more details here: https://ch2026.mini.debconf.org/talks/7-modernizing-debians-go-ecosystem-from-2011-time-travel-to-module-aware-builds People who join remotely during my talk may use IRC to forward the question to video team. I may answering in my talk. Transition Strategy from Ivan and Taffit ============================== During the event, I had face-to-face discussions with Ivan from the Release Team and Taffit from the Technical Committee regarding our modern, module-aware transition path. They offered a very good strategy to help us accelerate our progress for the Forky release cycle: 1. Upload new tooling to `unstable` with a new package name: Instead of keeping the module-aware build `dh-golang` version `1.66~exp+` in `experimental` or risking a long breakage for unstable packages. We may introduce the new tooling directly in `unstable` under a different package name. This allows us to polish the new tooling without breaking existing packages all at once. And also make the workflow works much simpler for maintainers to port their Go applications in unstable 2. Please suggest a new package name for new tooling: `dh-golang2` is just an example name. Other possibilities include `dh-gomod` or `dh-gowork`. Please share your thoughts if you have a better name in mind. :) 3. Deprecate legacy `dh-golang`: We may file an `important` severity bug against the legacy `dh-golang` package after the new tooling available in unstable. This is to announce the deprecation, and may upgrade to RC later when new tooling is more ready while we are approaching to the Forky freeze in the next release cycle. 4. Provide a transition package to enfore the transition when it's ready: Once we have more confidence on the new tooling, we can then provide a dummy/transition package to enforce the final migration from `dh-golang` to `new tooling` acrossing the archive. This is very similar to what Simon suggested before. But provide a different package name may make the deprecation more clear on legacy `dh-golang`. And easier to query the build-deps for transition status with new tooling name. It would be clear for maintainer to migrate their package to new tooling. And we don't keep support both build system in paralle for a long time. Please share your thoughts, so we can step forward and coordinate our translaiton better in go-team. Best regards, -- -Andrew
