Hi, On 7/1/24 04:55, Aigars Mahinovs wrote:
- if the NMU author has access to the main git repo of the package on Salsa they can make a commit and tag there (normal team-like maintenance)
If we create a method with a low technical barrier for NMUing, we also need to have a discussion about procedural expectations for that at some point.
Like, if someone makes an NMU that solves a problem, but creates maintenance issues down the line, is it acceptable to back that out immediately?
In a pure git workflow, it is understood that if you are not usually involved with the project, you'd send a pull request rather than merge directly, but since we're all somehow "involved" with Debian, I'd expect the barrier for just committing changes to other people's packages to be somewhat lower -- which may be good or bad.
- else the NMU author would have to fork the main git repo of the package on Salsa to their own Salsa namespace and create a commit and tag there. The NMUer would then create a pull request to the main repo and the maintainer approving this pull request would (quite cleanly) accept the NMU
So a NMU is more of a pull demand than a pull request? :>
There is no way to push a tag without having some kind of repo to push it to and you can't push just a tag without also pushing the code that you are tagging. So there is no technical way of uploading a package via t2u without also pushing the source to some kind of git repo (that is readable and is being monitored by t2u).
I kind of expect someone who is overenthusiastic about git to just create a repo for me if my package isn't yet "team-maintained", and it would be nice to define whether that is an appropriate course of action ahead of time.
Simon
