Hi Fabio, Fabio Fantoni <fantonifa...@tiscali.it> writes:
> 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 it >>> >> I 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) > Thanks for providing more real world use cases. I think these may help people (me included) understand the rationale on trying to suggest a name for the branch of the latest work better. >> >>>> >>>>> 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 >>>>> > -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
