Hi Arnaud and Mathias! > Can we agree to update the Go team policy to follow this and default > to 'debian/latest' going forward? > > There are <2000 packages in Debian that use the 'debian/sid' branch > name, and out of these ~1300 are from the Go team. The Go team should > not diverge from general Debian practices unless there is a proper > cause. The current situation is only due to historical reasons. > > I have to disagree with how you frame it. debian/latest is NOT "general > Debian practices". It's merely one of the possible default branch names that > is proposed in DEP-14, and it's not widely used in Debian at the moment [1]. > As we can see on debian-devel [2], lots of push back and different opinions > on what's the best name for the packaging branch. > > And as far as DEP-14 goes, debian/sid is a very valid name, so the Go team is > already following DEP-14 best practices here. > > Therefore I object to changing the default branch name at this moment. If a > project-wide consensus emerges in the future, we might revisit this > discussion.
Thanks for sharing your views. What comes to DEP-14 and timelines, do you agree that debian/sid predated the 2020 version of DEP-14 and the two options it now recommends are debian/latest and is some situations debian/unstable? I did not invent 'debian/latest' myself, I am merely raising discussion that since the Go team guide originally referred to DEP-14, it might be time to update it to match new version. Also my email on debian-devel@ explicitly solicits feedback _against_ 'debian/latest', so of course it will be dominated by views against it. I feel your line of argumentation is very defensive of status quo. It would be interesting to hear your view purely on what you would think the optimal branch scheme would be on it's own merits. I took checked quickly the packages you most recently contributed to (rebuildd, dput-ng, fierce, schroot, cadaver, wafwoof) they all seem to use either 'master' or 'debian/master' as the branch. Based on a small and possibly skewed sample you aren't using 'debian/sid' outside of the Go team. What would you then think of a policy that people can choose what branch name they want to use, as long as the git HEAD is maintained to always point to the Debian branch? There was several comments regarding the team policy discussion stating general distrust towards having policies. Could an option here be to update the Go team policy to say that a package can use any branch name in DEP-14? I would also be keen on hearing your (both Arnaud and Mathias) view on the other points. Would you mind reading the "Proposing 2025 workflow changes for Go team" and sharing your views on the other points so I can make an updated proposal that incorporates your feedback, and all the other feedback that are likely to drip in in the coming days. > It's difficult to have a peaceful discussion when the change being discussed > was pushed out on the team already. This is not true. I suspect you are having this sentiment because Guillem's communication style is confrontational and dishonest, and you entered the discussion having read only his false accusations. I invite you to skim throught the mailing list history since September and look at the MRs and PRs: https://lists.debian.org/debian-go/2024/09/ https://lists.debian.org/debian-go/2024/10/ https://lists.debian.org/debian-go/2024/11/ https://lists.debian.org/debian-go/2024/12/ https://lists.debian.org/debian-go/2025/01/ I have been raising ideas on the mailing list for discussion, provided examples, promised to do my part in the implementation, listened and responded to all who shared their views etc. On Dec 8th I specifically raised on the mailing list the question on how decisions in the Go team work and got advice (thanks Nilesh) on who are the stakeholders (https://lists.debian.org/debian-go/2024/12/msg00030.html). Unfortunately none of them have replied to any emails. I have sent several emails to Anthony Fok who seems to have been the main maintainer for the team tools in past years, but unfortunately he hasn't responded either. If people are missing then the remaining volunteers need to try do their part, and I have diligently done. I have waited a long time, just like is best practice in Debian. Some of the comments of "only in software companies" don't feel correct here. The Go team already has a policy, and it was to my knowledge a volunteer team when the policy was made Updating it every 5 years is fully feasible for a volunteer group like us and not something only software companies can do. I published the proposal or the proposal as an MR, and revised it based on feedback in both the MR and on the mailing list. Putting out the proposal now was a perfectly fair and proper course of action to get more visibility and solicit more feedback. I would love to hear more views. Please Arnaud and Mathias participate in the mailing list discussions so we can proceed productively. I know from experience that following mailing lists can be boring and is away from actual packaging work, but these workflow discussions are not useless, but on the contrary the foundation for collaboration, necessity to attract new contributors and ultimately a major factor in how useful our volunteer time can be. To quote https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/ > Personally, I cannot keep enough details of the different workflows in my > head. Every time I touch a package that > works differently than mine, it frustrates me immensely to re-learn aspects > of my day-to-day. > > After noticing workflow fragmentation in the Go packaging team (which I > started), I tried fixing this with the workflow > changes proposal, but did not succeed in implementing it. The lack of > effective automation and slow pace of changes > in the surrounding tooling despite my willingness to contribute time and > energy killed any motivation I had.
