Le sam. 25 juil. 2026 à 11:10, Otto Kekäläinen <[email protected]> a écrit :
> 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 > Improving dh-golang is surely a good idea. dh-nodejs helped us a lot at js-team. It made things a more bearable. > 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. > Doing large-scale changes like that surely require some level of consensus. Otherwise, improving dh-golang and uscan to e.g. support versions in go.mod, would help a lot (while probably break things for a while) and improve automation.
