Hi, > +1, I'm also not a fan of monorepos or repositories which only contain > debian/.
Monorepos could make sense for Debian perhaps in the future if the overall packaging workflow and packaging formats converge clearly on something. Until that happens, jumping directly to a monorepo would alienate many people who would essentially be forced to redo all their workflows immediately in one go. Hence I would not recommend it for now. > But concerning the initial question (changing multiple packages at > once), isn't that exactly what the Debian Janitor[1] excels at? I guess > we could talk to Jelmer about adding go-specific tasks (or maybe come up > with patches ourselves, I haven't look at the code). > > IIRC, the Janitor can even be configured to automatically commit the > changes to the repository, so there would be no need to manually merge > all changes. Janitor is a Salsa bot that runs lintian-brush on packages, and files the results as Merge Requests. You can just run lintian-brush yourself every time you touch a package to have lots of changes fixed automatically. My `debcraft improve` runs lintian-brush and several similar tools under the hood. In general, the way wide-scale changes are done in Debian is either by a) change in a build tool (e.g. dh-golang) which once uploaded will make all builds/packages behave in the new way or b) change in policy, communicating that to all maintainers and updating tools such as lintian and lintian-brush to automatically detect and fix the issues in the packages that need to be updated Currently there is no fast/easy technical way to do changes to multiple packages (e.g. via monorepo), nor do we have any social/organisational way to do it, as reaching any decision takes endless amount of discussion and vague consensus, and there is no clear way to propose changes and have them voted on in a binding way (apart from the GR as described in the Debian constitution, but that is overkill in most day-to-day changes we want to drive). This is e.g. why Stapelberg stopped being active in the Go team as described in https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/. I have a feeling we should solve the social/organisational way first on how to make decisions that affect all or most packages before we are ready to have automation such as monorepos or Flight Deck to do changes on a lot of packages in parallel.
