Re: Rename master branch to main
* Sébastien Villemot <sebastien@debian.org> [2021-08-09 13:20]:
Le vendredi 06 août 2021 à 18:11 +0200, Rafael Laboissière a écrit :
Please, check the octave-brain2mesh repository and let me know if there
are any problems. If everything is okay, I will launch the script and
update all the repos.
Thanks for updating all the repos.
I did a few further cleanups:
— deleted master branch of octave-optiminterp, which was left behind
for some unknown reason
— renamed the codename branches (buster, buster-backports, …) of octave
and dynare, to follow DEP-14 (debian/buster, debian/buster-backports).
I did not adapt debian/gbp.conf, this will have to be done later if
those branch get further updates. Note that you will also have to
update your local repositories manually (git fetch --prune, then git
branch --set-upstream-to=…)
— fixed debian/gbp.conf in dh-octave (this is a native package)
Thanks for all these cleanups!
— my impression is that DEP-14 encourages us to rename debian/stretch-
backports to simply “stretch-backports” in the case of dh-octave, since
this is a native package. But I’m not 100% sure.
I am not sure neither.
— there are branches that I don’t know how to adapt to DEP-14:
— 3.8 and 4.2 branches in octave repository. Those were short-lived,
used to store a single upload in each case. Should we rename them to
debian/3.8 and debian/4.2? or delete them? (the tags would still
remain)
I do see these branches in the repo at
https://salsa.debian.org/pkg-octave-team/octave/-/branches
— the “hg” and “upstream-hg” branches of octave-odepkg. I don’t know
their purpose
This package has been removed from Debian in 2019. I would simply
forget this.
— the octave-pkg-dev repository got branch renames (including a new
upstream/latest which does not make sense since this is a native
package). Actually this package has been removed in 2018, and it got
several updates since. I guess this is an overlook, due to the fact
that you use an automated tool
The octave-dev-pkg package is obsolete. Just forget it.
By the way, there is a way to archive repositories in GitLab. According
to the description: “Archiving the project will make it entirely read
only. It is hidden from the dashboard and doesn't show up in searches.
The repository cannot be committed to, and no issues, comments, or other
entities can be created”.
Should we archive the obsolete repos? When querying through the API, we
can set "archived=false" to filter out the archived repos.
The following repos could be archived :
octave-odepkg
octave-ocs
octave-pkg-dev
What do you think?
Rafael
Reply to: