Hi! Thanks Tina for following up on the mailing list!
> > Can we agree to update the Go team policy to follow this and default > > to 'debian/latest' going forward? > > I strongly oppose this: not only it would create an enormous amount of > churn, but it is also a regression as many have already highlighted. Noted. By churn you refer to the work of renaming branches? And by regression you mean that you having the newest version of the package, the git default branch and the target for new changes in 'debian/latest' having occasional uploads to experimental? I think that way of using 'debian/latest' is intentional. When people prepare improvements to a package they would push to 'debian/latest' (or open a MR targeting 'debian/latest') and the changelog would say UNRELEASED. Then when it is actually time to release, the uploader would choose if they put it into unstable, or if there is a reason to put it into experimental first and only later upload to unstable. For example when preparing a new version of golang-golang-x-net, which has massive amount of reverse dependencies, we might at upload time decide to put it into experimental first. While it is in experimental we might want to fix something, or somebody else might pop up and contribute some additional fix. If the process requires changing the branch name and git default branch in order to upload to experimental, and then change back to 'debian/sid', it seems it would be flip-flopping. Seems you are not flip-flopping like this at the moment but doing something else? Can you perhaps point out a repository where you used both sid and experimental branches recently? I looked at which package Guillem most recently touched in the Go team, and it was https://salsa.debian.org/go-team/packages/golang-opentelemetry-contrib/-/branches that has both master, debian/sid and debian/experimental. If I were to open a MR to fix something in this package it would default to 'master' as it is not the default branch, but that is probably not the intent. Eventually I checked the d/changelog in all branches and it seems the current actual development target is https://salsa.debian.org/go-team/packages/golang-opentelemetry-contrib/-/blob/debian/sid/debian/changelog, but it was never maintained in parallel in both sid and experimental, so it would have been on a single branch all the time. This might not be a representative repository - I am happy to read your explanation or look at some other example you point out. > It seems backwards to try to start this homogenisation effort with a > team that has had a pretty homogeneous workflow for years, instead of > tackling the mess that is the rest of the archive... This is not a homogenisation effort. This is an effort to help new maintainers learn Debian packaging with reasonable effort, and by having optimal defaults documented so they don't have to spend too many cycles on making decisions about details such as branch names package-by-package. Go team is great in the sense that it has a documented default way of doing packaging, and a tool to automatically do much of it, but as I found a lot of things that look outdated in my eyes I started a discussion 3 months ago about potential updates. If you look at the various team repositories we have also done technical maintenance. I invite you to review current MR/PR at e.g. https://salsa.debian.org/go-team/packages/dh-golang/-/merge_requests and https://github.com/Debian/dh-make-golang/pulls if you have time. > > I don't see any good arguments to use 'debian/sid' on Go team forever. > > Many good arguments were given and disregarded. Please avoid such ad-hominem type of arguments. Clearly I have diligently followed up on all discussion on the mailing list and incorporated all feedback as much as possible. It would be more productive if you rehash the key arguments you support. Becoming active now on the mailing list is of course first step in that, thanks for writing this email. Hopefully you can follow-up now when you know there are such discussions going on. > > With a couple simple updates to our tooling we can slowly start > > converging on the 'debian/latest' recommended by DEP-14. This is a > > small but important detail in updating the Go team workflow for 2025 > > and converge on practices that are common with other teams, and > > eventually simplify the workflow, and have it more productive for > > current DDs and easier to learn for new and aspiring DDs. > > This highlights something I have been feeling since the discussion > started: you are pushing pretty hard for changes on a team that you only > joined very recently, and where your only contributions seem to be > unilaterally applying your idea to existing packages. I don't want to > say that newbies should not try to instil new ideas and energy into the > team -quite the contrary-, but I think you should really try to follow > and understand current practices before proposing to change them. I think I have enough understanding to be allowed to propose changes. I have also backed up those changes by doing feasibility research and posting code changes to show that they are doable. That 'your only contributions' does not seem like a fair characterization. Please check out https://salsa.debian.org/otto and please stick to arguments about the actual changes and not about the person making them. I put a significant amount of time in making sure the proposals are sound, and I have spent many months doing them slowly so that people have time to voice their opinion. And I will continue to wait until Aloïs and Anthony replies, as Gulliem has now clearly stated that they are part of the "Go team" who's opinions are to be listened to before doing anything. > So, all in all, I would support a proposal that: > > 1. Recommends `wrap-and-sort -tsa`, along with changes in default > settings for dh-make-golang. > > 2. Recommends switching to the `upstream/*` namespace for following > upstream branches, to ease tracking different upstream repositories, > repackaging commits, etc. A tool to automate this switch would go a long > way towards adoption. > Note that DEP-14 -as well as git-buildpackage- does not care about these > branches, as only upstream/* tags are used during builds. Thanks, reducing the changes to these two things is one way to proceed. The upside is less change at once, but downside that the duration when things are in flux stretches out. Many have also stated they don't think a team in Debian shouldn't act as if it has rules/guidelines, as it is not a software company, so perhaps another avenue is to simply remove something from the policy instead of updating them to recommend something else. But let's continue to wait to ensure more people have a chance to chime in.
