Hi, On Tue, 07 Jan 2025, Marco d'Itri wrote: > Like many others, this looks like a gratuitous change for change's sake. > Countless packages have been using "upstream" for years, but apparently > it is not perfect enough and somebody had to invent a new name.
It's difficult to have figures for this since the name of the remote is a local choice. There have been cases where I used "upstream" too but indeed it clashes with the namespace that the DEP recommeds for local branches and tags for the upstream import. So "upstream" is not a good choice. Given that the "upstream" branch name cames from the git-buildpackage and that it's git-buildpackage which introduced "upstreamvcs", it seems fair to me to standardize on this name. > I still believe that this is trying to codify a lot of pratices (e.g. > the obsession with pristine-tar) which are not widely accepted. > This DEP is the result of an echo chamber and is the consensus of the > few people debating it on salsa. I never pushed further earlier because I had that feeling in the early years but I believe this has changed lately. That said I don't have figures to back it up and I agree it would be nice to have some concrete figures of adoption (as Lucas suggested). > > +The codename can also be prefixed with the version so that branch names > > +are correctly sorted by age of the target release in the list of available > > +branches. Examples: `debian/12-bookworm`, `debian/11-bullseye`, > > +`ubuntu/24.04-noble`, `ubuntu/22.04-jammy`. > So to gain optional sorting now you lose the benefit of being able to > mechanically determine the branch name? This is beyond silly. This "mechanical determination" has never been true unfortunately, the DEP allows the use of "codename" as well as "suite" as well as "latest" depending on the different use cases. So the reason why I accepted this is that we're not going backwards in the fact that you need to list all the available branches to figure out which is the correct one that you are looking for. > > +unlikely to clash with the packaging branches. Despite this, it is good > > +practice to not push any upstream branch to the packaging repository so as > > +to not confuse anyone about the purpose of the Git repository. > WTF? I say instead that in the modern worlds it is a best practice to > have the packaging repository as a branch of the upstream repository. > Again, trying to promote personal preferences to a standard. It can certainly be a branch of the upstream repository (and the DEP does document that workflow as one of the recommended ones), but that's not a reason to have more than the upstream tag in your packaging repository since that's what you merge in your packaging branch. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
