Hi, On 5/21/24 10:43, Luca Boccassi wrote:
The ecosystem, however, does not support our workflows, and adapting it to do that is even more effort than maintaining our own tools. [...]
That's a problem of our workflows, which are horrible. The solution is not to double down on them.
Our workflows are largely influenced by what we do here: we maintain packages. This is different from "developing software", or "operating infrastructure."
If we can improve the workflows, then I'm all for it. What does not work, however, is to replace them with workflows from a different task.
All we are doing here is providing a mapping of the packaging workflow onto a git software development workflow. It still remains a packaging workflow, because the *goal* of the workflow is the completion of packaging tasks.
Providing an implementation layer does not change the goal layer, and GitLab does not provide any tools on the goal layer.
If we had buttons in GitLab "import new upstream release" or "show issues affecting the stable release branch", I would consider that as support for a packaging workflow. As it is now, GitLab only supports the workflows that the implementation layer below the goal layer typically uses, including workflows that break the upper layer.
At the very least, GitLab integration would allow me to automate such a simple thing as changelog handling in a more comfortable way than displaying instructions how to download the conflicting branch into local git, resolve the conflicts manually, and force-push the branch to solve the problem.
gbp dch --commit --release
Where is that button in GitLab?That's my point: GitLab is a step *back* from the commandline tools for git integration.
Simon