Hi, On Mon, 2025-08-25 at 22:15 +0200, Lucas Nussbaum wrote: > On 24/08/25 at 15:53 +0200, Lucas Nussbaum wrote: > > On 21/08/25 at 12:15 +0200, Lucas Nussbaum wrote: > > > Hi, > > > > > > There was consensus during the DebConf BOF that we should migrate > > > to > > > DEP-14. I plan to work on that. > > > > Hi, > > > > I wrote¹ a script that uses the GitLab API to migrate a project to > > DEP-14. > > See > > https://salsa.debian.org/ruby-team/meta/-/blob/master/dep14-migrate?ref_type=heads > > > > I will start using it to migrate repositories, starting with the > > easier cases first. > > Reviews of the script welcomed. It will probably need some > > adjustments > > for the more complex cases. > > So this went well, and I migrated all non-native packages to DEP-14. > > The migration also included renaming most other branches (for > example, > for backports, fasttrack, etc.) to the new layout, but there is still > some cleanup to on a per-package basis. > > Also the script is robust and could be useful for other teams. > > I took special care of the packages that track upstream branches in > our > git (with upstream-tree = tag in gbp.conf). They should all be OK. > > If I broke something, I have forks of all salsa projects in my own > namespace. > > Remaining To-Do: adjust our defaults in gem2deb, ./setup-project, > etc. > (I will work on that, but I'd like to conclude the work on > debian/salsa-ci.yml and debian/.gitattributes first) > > Remaining optional To-Dos: > - for each repository with additional branches, review them and > cleanup > - further homogeneize debian/gbp.conf across packages, so that > packages > that try to do the same have exactly the same file. Is there a way to forbid people to keep pushing let's say a "master" branch? Not sure if you have done that already (AFAICS you have not), but I can see myself, while working on many packages (i.e. interpreter transition), applying changes in my local repo and "git push"ing it without even noticing that I am messing up with the branch layout. Ideally, I should remove my local repo and check it out again, but that is not applicable to every package since I may have staged local changes. There is this concept of a protected branch in Gitlab, not sure if we can use it to avoid this type of mistake. I played with it in one of the repos and I think we can protect any branch matching the *master* wildcard, and only maintainers can merge (in case of any exception) and no one is allowed to push and merge. It works: $ git push origin master Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) remote: GitLab: You can only use an existing protected branch ref as the basis of a new protected branch. To salsa.debian.org:ruby-team/rubygems.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'salsa.debian.org:ruby- team/rubygems.git' We could extend your script to add this configuration to all repos. WDYT? Lucas Kanashiro.
Attachment:
signature.asc
Description: This is a digitally signed message part