On 27/08/25 at 02:15 +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Lucas Nussbaum (2025-08-26 09:52:42) > > On 26/08/25 at 09:33 +0200, Simon Josefsson wrote: > > > Are your scripts to do these mass-commits available somewhere? > > > > > > I've often wanted to apply the same kind of fix to many packages at the > > > same time, but I mentally queue them and apply them when updating a > > > particular package once it is time to work on that package. This can > > > take months to complete, and probably leads to mistakes. > > > > Yes > > > > the main script to migrate a given project to DEP-14 is > > https://salsa.debian.org/ruby-team/meta/-/blob/master/dep14-migrate?ref_type=heads > > that sounds like a useful tool for devscripts, no?
I thought about it but I'm not sure: at this point, I think it's useful as an example of how to perform such a migration in a large team, but it encodes some of the Ruby team's preferences. I would expect other teams to use it as a basis and adjust it to their own preferences, not to expect it to meet their needs as is. But maybe after one or two other teams will have adapted it, it could reach a state that is sufficient for serving as-is for other teams. > Otto has already created a tool called dep-14-convert-git-branch-names: > https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/dep-14-convert-git-branch-names.sh Yes, the main difference with dep12-migrate is that dep12-migrate does everything through the GitLab API -- it does not need a local copy of the git repository, so it's more efficient when migrating many packages. Also dep12-migrate performs the actual migration, while dep-14-convert-git-branch-names.sh only suggests what should be done. Maybe what dep14-migrate does should be integrated into the salsa(1) tool. Currently salsa(1) does not have really have multi-steps processes, but could have. The reason why multi-steps processes are required in that context is for the branch renaming: 1/ to rename upstream to upstream/latest, you need to create a temporary branch, remove 'upstream', then create 'upstream/latest' (upstream/latest and upstream cannot coexist because of the common prefix). 2/ after a branch is renamed, it takes some time (30 seconds max) for GitLab to reflect this in API calls that list branches. So it's useful to just rename all branches, then wait for things to settle, then use the new branch schema to update debian/gbp.conf. Lucas
