Re: finally end single-person maintainership
Hi Simon!
> > 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.
Not exactly, I said it is unnecessary work and doing it will just
cause more work.
Exact quote: "These commits have intentionally no debian/changelog
updates as it causes every single rebase or cherry-pick of a commit to
always have a merge conflict. It is much better to have all commits
as-is, and then right before upload just run gbp-dch --auto to
automatically generate the changelog."
Thus better not to inject debian/changelog changes in every single
patch and instead..
> > 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
..just let automation handle it, like Luca and many others already
know. Personally I prefer the variant `gbp dch --verbose --auto
--release` but essentially it does the same thing.
Anyway, thanks Simon for doing a review on
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19, at
least I know you have tried using Salsa and are speaking from a point
of some experience when criticising it (unlike apparently many
others).
Back on-topic of single-person maintainership - has anyone made a list
of which packages have only *one* maintainer/git committer and are in
the set of top-1000 or top-5000 Debian packages? We should perhaps ask
those people why they don't have co-maintainership, and why they
resist sharing the development work. Debbugs is one example - it has
multiple open MRs and patches in the bug tracker but somehow the sole
active maintainer does not see value in granting more people commit
permissions. If we learn how these maintainers think, perhaps we can
come up with a model to facilitate having more co-maintenance that can
apply to the exact cases where co-maintenance is missing.
- Otto
Reply to: