Il 24/01/2025 22:24, Xiyue Deng ha scritto:
Fabio Fantoni <fantonifa...@tiscali.it> writes:...There is also another thing to consider, if you keep a generic one as default it always points to the latest version, while a specific one might not be the latest version and if the contributors do not check well the branches they could risk wasting time (and maybe also the reviewers) doing work that does not include work in progress on more recent branch or that conflicts with itI would like to echo on this point. I had worked on a repository that has the "master" branch marked as the default branch on Salsa, which lacks many changes compared to the released version. I tried to manually incorporate those changes, and only later found out that the actual latest branch is "debian/sid" and it did have everything up-to-date. (Note that this has since been fixed[1]). I think for new repository, standardizing on a name (either "debian/latest" or people's liking) helps identify where the latest work goes to. And as Salvo pointed out, it's the tag names that indicate where the releases go to, not the branch names. [1] https://salsa.debian.org/debian/mozc
I wrote this because I also saw this issue over the years.Check the tags is useful if there are new upstream or debian version (so new tags) but not unreleased work excluding new upstream version, this require to look on branches those with the most recent activity, excluding those of fixes released for stable and backports.
It might seem obvious but unfortunately it is not, I fear that someone does not check by looking only at the default branch or maybe quickly not noticing something, for example in cases with particular and different names that are not common, linked to versions of the distro or software (at least not numbers).
For this reason, trying to standardize with a single name the branches where the most current work is carried out (with some exceptions), if not recommended by DEP-14 (because in some cases it is counterproductive) but at least suggested being able to have in the future the majority of uniform gits I think can be useful.
Then there were cases where the problem was that the default branch was no longer actually used but was not updated, so in addition to the name it would be good to make sure to keep the default branch updated. I have seen for example cases of those who created the repository with master but then immediately used another working branch (like "debian"), or who had switched from master to main but kept the default on master and these are just 2 examples of what I had seen.
While I was finishing I saw @zigo's answer regarding this last part, "default branch being set correctly should be what we mandate" would help even if is not for all cases (excluding any separate branches for "test" work, that is ok more updated but not default)
2 other particular cases that hinder could also be when someone work on another git without updating the fields in d/control and that do not work on the default branch because maybe only someone with lower permission remained active in the repository and who cannot push to the default branch by setting (rare but it happened), it would be necessary to better define how to act (and also have the means in some cases) to reduce the problematic cases to which I add a last example, "abandoned" package in which those who continue cannot modify in the repository and proceed in another repository but unfortunately until a new upload is made with the updated vcs fields others don't know and there is a risk of doing duplicate work elsewhere (it happened also to me)
There were cases when git wont let me use debian/foo "branch subdir" since it clashed with other objects in the git repository, but I don't remember what it was.(Maybe that you cannot have <$branch> and <$branch>/something)Thanks, /mjt
OpenPGP_signature.asc
Description: OpenPGP digital signature
