Re: finally end single-person maintainership
On Tue, 21 May 2024 at 03:16, Simon Richter <sjr@debian.org> wrote:
>
> 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."
Not really, our workflows are mainly influenced by whatever was
available in the late 90s and has just kept chugging along on life
support - hence FTP uploads, GPG signing tarballs, sending commands
via emails. There are plenty of ways to maintain packages that do not
involve any of that - see SUSE's OBS, etc.
> 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.
There's factually no need for any of that. As per
https://trends.debian.net/ most packages today are on Salsa despite
the lack of these buttons. The goal is to have an actual source code
management system that allows forking, branching, rebasing, merging,
navigating history, running integration tests. The fact that at some
point one has to interact with crufty old ftp servers and dusty
tarballs is not really relevant. Having a pipeline stage at the end of
salsa-ci that does an upload for you would be a nice improvement, but
it's by no means necessary to use Salsa effectively and productively,
as the vast majority of cases are already showing in reality.
> >> 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?
If that is needed, why isn't there a button on the ftp server instead of dput?
Reply to: