Hi Adrian, On 23/12/25 at 01:33 +0200, Adrian Bunk wrote: > On Mon, Dec 22, 2025 at 04:16:38PM +0100, Lucas Nussbaum wrote: > > Hi, > > Hi Lucas, > > > On 18/12/25 at 10:56 +0200, Adrian Bunk wrote: > > > If you want to actually be able to use that for audit purposes, you > > > might not want to work with the maintainer-specific mess that Salsa is. > > > > > > Only debian/ or complete sources? > > > debian/patches/ or patches applied? > > > One git repository per package, or 1k packages in one git repository? > > > > Isn't this mostly solved either by using git-buildpackage together with > > debian/gbp.conf (to describe the workflow in use) or by team-specific > > helpers (such as pkg-haskell-tools)? > > ~ 99% of my uploads are in packages where I am not a maintainer, and > I am trying to stay away from touching git for that due to the diversity > of ways how maintainers want an NMU integrated into git when there are > janitor commits or a one year old aborted upgraded attempt or anything > else I do not want to include in an NMU on the branch.
Ah, yes, sure, NMUs are better handled outside of Salsa, and in that case there's no way to link the source package and the git history. However, I'm not sure it's a big problem, since the NMU will be based on the previous upload (for which the source<->commit link could be available), and only add minimal changes (since it's an NMU). > Existing maintainer workflows for merging an NMU include: > - asking to submit an MR > - create a commit and merge into the branch > - manually merge the changes on top of the branch > - force-push the NMU, breaking history > - manually revert other changes, and commit on top > > It is obvious that not in all cases a commit ever existed that matches > the NMU upload, but people who want to use salsa git trees for audits > might make such an incorrect assumption. However, the source<->commit link for the next maintainer upload would still be correct, and the sequence of commits between the two maintainer uploads will tell a correct story about the package, so I'm not sure I see a problem here. I think that our aim should be to include that information when it is available and correct, and not to try to enforce including in other cases. Lucas
