Hi,
On 4/5/25 19:41, Daniel Gröber wrote:
I only joined Debian in 2024 and since then one thing has become abundantly
clear to me: it's dying because potential contributors are put off by our
archaic, fragmented and most importantly not natively git-based workflow(s!).
Git is not a packaging tool. There is no way to have a "native"
git-based packaging workflow.
Any distribution that uses git internally has a stack of other tools on
top, contributors need to learn these, and support for these tools in
the forges is bad to nonexistent. The best forge for Debian development
at this point is Launchpad, because it was at least designed around the
needs of packagers.
What they will do, very readily and with much gusto is hop on GH to file an
upstream bug or shoot a patch — no problem.
Yes, because this is what forges and git are designed to make easy.
Contributing to a package through a forge is an entirely different
beast: you either work locally, using distribution packaging tools, or
you pretend the tools don't exist, make changes through git, wait for CI
to complete, then interpret the error message, again from a distribution
packaging tool, to find out what you need to do to try again.
We cannot save people from having to learn how packaging works, and
creating false equivalences is making it even harder for people to
contribute, because they will soon run into a situation where the
existing knowledge is the opposite of the correct approach.
I can explain the sequence
1. use 'apt source x' to get the source package
2. use 'apt build-dep x' to install the build dependencies locally
3. build the package with 'dpkg-buildpackage -b -us -uc' to see that it
works
4. use 'dch -i' to create a new changelog entry
5. make local changes
6. rebuild the package, test if it works, if not go back to 5
7. use 'dpkg-source --commit' to create a patch file for changed
upstream sources
8. use 'dpkg-buildpackage -us -uc -S' to create a new source package
9. use 'debdiff old.dsc new.dsc' to create a diff
10. use 'reportbug' to submit a bug report, and attach the diff.
This works for *any* current Debian package. I fully agree this could be
improved, but none of the git-based workflows are an actual improvement,
and that there are multiple git-based workflows is a further hindrance.
Even "how you create a changelog entry" is not uniform, much less "how
to register a patch" or "how to rebase patches for a new upstream version."
The git-based workflows are a great collaboration tool, but to use them
you already need to understand the Debian packaging tools and git, then
on top there is also the policy on how branches inside the repository
are used.
Not just of t2u, but the incremental improvements it enables. Their
inaction has cost us four years of new, young, motivated people joining the
project and actually improving things alongside us.
t2u does not change anything for people freshly joining. I'd expect the
opposite, actually: new contributors will be expected to use a
package-specific patch submission system, and will frequently be told
that the method they used on their last submission is incorrect for this
package because it uses a different repository layout.
Deploying t2u is completely orthogonal to our inability to onboard new
people. It makes sense to deploy t2u because it will be useful for a lot
of our seasoned developers, and the only danger I see is that it will
create an even steeper learning curve for people freshly joining.
Simon
