Hi!

- because it is not easy and fast to migrate and if you do it you have to redo the local repository, if you are alone working on the repository it is not a big problem while if you are many it can create inconveniences

IMO this is the real hurdle.
Migrating thousands (in the case of pkg-perl) repos both remote/on
salsa and locally (for dozens of team members) is not trivial, and
AFAIK noone so far has come up with working tooling.

I wrote and rewrote this script a couple of times in past two months: https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/dep-14-convert-git-branch-names.sh

It's not exactly ideal yet, but it does the job. The name is a bit
stupid, and it only outputs the commands it recommends users to run,
it does not actually execute them (yet). In hindsight it became a bit
more complex than what makes sense for a shell script. Simon also
pointed out that the way the `salsa` script (that this uses) stores
API keys in plain-text isn't exactly ideal for security.

Jeremy: You mentioned Debian team is migrating branches. Perhaps you
can test this and collaborate on polishing it?

In general, if anybody wants to take a stab to improve it, feel free
to add me as reviewer in MRs targeting this script.

- Otto

PS. Props to Johannes SMR for reviewing and testing the script in past months!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Otto Kek�l�inen <[email protected]> [250128 00:04]:

I wrote and rewrote this script a couple of times in past two months: https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/dep-14-convert-git-branch-names.sh

It's not exactly ideal yet, but it does the job. The name is a bit
stupid, and it only outputs the commands it recommends users to run,
it does not actually execute them (yet). In hindsight it became a bit
more complex than what makes sense for a shell script. Simon also
pointed out that the way the `salsa` script (that this uses) stores
API keys in plain-text isn't exactly ideal for security.

Jeremy: You mentioned Debian team is migrating branches. Perhaps you
can test this and collaborate on polishing it?

In general, if anybody wants to take a stab to improve it, feel free
to add me as reviewer in MRs targeting this script.

Please listen to Colin:

* Colin Watson <[email protected]> [250126 15:35]:

In the situation you outlined, it wouldn't have mattered to me one bit whether the actual latest branch was called debian/sid or debian/latest;
I probably wouldn't have noticed it either way. What would have
mattered to me was that it wasn't the default branch (HEAD on Salsa).

So, rather than worrying about the _name_ of the default branch, I'd
like to suggest a change to DEP-14 that I think would have broader
consensus and be more useful.

Please re-read his entire message.

You started with a goal of making contributions easier for people who
are not part of the packaging team for a particular project. You then postulated that standardizing certain things would at least be part of
the solution, and so DEP-14 was born. Overall, this is excellent work!
Thank you.

One of the things you postulated was that the name of the default branch
was one of the items that should be standardized. This was a reasonable assumption. But as Colin points out, the real issue is not the _name_
of the default branch, but that the salsa repo _correctly_ identifies
the default branch, which apparently is not being done for all projects.

This thread has clearly shown that much contention exists for mandating
a specific name for the default branch, at least for existing projects.
Even if you wrote the perfect script to change existing projects to
conform, one that handled all edge conditions properly without human intervention, the amount of churn, not only on salsa, but also on
_thousands_ of contributors' personal machines, would be **massive**.
And all this when simply mandating that the salsa repo have HEAD set
correctly would solve the problem.

It has also been pointed out that there are some projects (esp. larger
ones) where primary development occurs on multiple different branches.

I strongly urge you to heed Colin's suggestion. Have DEP-14 _require_
that the salsa repo have HEAD set to the branch where new contributors,
NMUers, and others not familiar with the project should be making
changes. Then _suggest_ that _new_ projects use a specific branch name
for this purpose.

Thank you for both your enthusiasm and your effort on this project.

...Marvin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Gioele Barabucci <[email protected]> [250128 08:03]:

DEP-14 could have a stronger message, but the requirement for HEAD to point to the development branch is there.

My mistake. I was basing my reply on Colin's message:

* Colin Watson <[email protected]> [250126 15:35]:

Currently, there's only one place where DEP-14 talks about the default branch: the "Native packages" section says "the default branch of the repository (as pointed by the HEAD reference) should be a development branch". I suggest that this recommendation should not be just for
native packages. The "For development releases" section should say that
the branch for uploads to the current development release of the furthest-upstream distribution handled in a given repository (typically Debian) should be the default branch, as pointed to by the HEAD
reference.

That doesn't nullify my (or Colin's) request to change the requirement
for a specific branch _name_ to only be a suggestion for new projects.

This would avoid the unnecessary, massive churn of renaming branches for existing projects (and GNOME, apparently, has already done this once for
this DEP).

...Marvin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 28, 2025 at 02:02:46PM +0100, Gioele Barabucci wrote:

On 28/01/25 13:57, Marvin Renich wrote:

I strongly urge you to heed Colin's suggestion. Have DEP-14 _require_
that the salsa repo have HEAD set to the branch where new contributors, NMUers, and others not familiar with the project should be making
changes.

From https://dep-team.pages.debian.net/deps/dep14/:

[Packaging branches and tags] NOTE: If the Git repository listed in debian/control's Vcs-Git field does not indicate an explicit branch
(with the -b <branch> suffix) then it should have its HEAD point to
the branch where new upstream versions are being packaged (that is
one of the branches associated to a development release). The helper
tools that do create those repositories should use a command like git symbolic-ref HEAD refs/heads/debian/latest to update HEAD to point to
the desired branch.

and

[Native packages] However the default branch of the repository (as
pointed by the HEAD reference) should be a development branch.

DEP-14 could have a stronger message, but the requirement for HEAD to point to the development branch is there.

Oh. Maybe this is my problem then, but the fact that I missed this even
when I was specifically trying to find it suggests that there might be a problem. Maybe it should use the phrase "default branch" in both
places?

And yes, Marvin is right to point out that I'm saying that the branch
name should be something we take into account for new repositories
rather than something we try to impose on existing ones. No matter how
much you polish a script to do the renaming in bulk, the change is still
going to be disruptive to anyone who has a local clone of any of the
affected repositories at the moment. So maybe let's spend time on
something else instead.

--
Colin Watson (he/him) [[email protected]]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)