Re: finally end single-person maintainership
On Tue, 21 May 2024 at 02:08, Simon Richter <sjr@debian.org> wrote:
>
> Hi,
>
> On 5/21/24 07:43, Bernd Zeimetz wrote:
>
> > Also its a gitlab instance. There are all kinds of documentation,
> > tutorials, videos and software for/about gitlab, including lots of
> > beginner friendly options. There is a whole ecosystem around gitlab, it
> > does not depend on a few (two?) developers.
>
> The ecosystem, however, does not support our workflows, and adapting it
> to do that is even more effort than maintaining our own tools. We would
> not even save effort in onboarding, because we'd still need to explain
> the Debian specific aspects, only we would now also need to explain
> which parts of the git workflow we can keep and which parts don't work
> for us.
That's a problem of our workflows, which are horrible. The solution is
not to double down on them. Simply due to demographics, the number of
people who can actually stomach them, let alone maintain them, is only
ever going to shrink.
> The workflows of GitHub (more deployment focused) and GitLab (more
> development focused) are already different enough that I have seen
> organizations struggle after making the wrong choice.
Most large organizations and most distributions have additional
tooling on top of git to perform certain tasks, that's really not a
problem nor surprising, because it's still git and everyone
understands it. Going from git push to gbp push when importing new
releases is really not that disruptive.
> git-buildpackage is not a good mapping of packages to git, but the best
> you can do without modifying git itself. Actually using it requires more
> than beginner-level knowledge of git and suspension of any previously
> held convictions that every single commit should be buildable (because
> gbp likes to generate ones that aren't).
Only when importing new releases, so not really an issue. "Every
commit builds" is a good aspiration but it is incredibly rare that it
is 100% the case with no exception ever at any point in the history of
a repo.
> A better approach would not treat Debian metadata as git data. Even the
> most vocal advocate of switching everything to Salsa writes in his MR
> that the changelog should not be touched in a commit, because it creates
> conflicts, and instead a manual step will need to be performed later.
>
> 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
Reply to: