Having mostly the packages in the same place (salsa), with the same methods/tool (with gbp) would be useful, obviously not preventing you from using or continuing with something else, but if you want to aim for this thing you should firstly have a complete, simple and fast documentation that mainly aims at this goal.
Today trying to see how a new person who wants to start maintaining new packages would do and trying to do research thinking from his point of view and from simple searches on the internet I found unfortunately that these parts are fragmented and do not help at all to aim for something unified but not even simple and fast enough.
Write on Google "Debian create new package" and first result: https://wiki.debian.org/HowToPackageForDebian
It points to various parts but mainly the more probable start point seems https://wiki.debian.org/Packaging/Intro
To point to git and gbp seems more useful https://wiki.debian.org/PackagingWithGit Here wrote also about DEP14, tell writing first package out of git and after import, in fact it is not simple and fast to create the initial package starting immediately from git and neither to use immediately gbp and also DEP14, to create immediately on salsa etc... I remember that the last packages created new some time ago I had to do many steps, workarounds and only after convert the branches to the DEP14 names.
What would be the best, easiest and fastest procedure (especially for newcomers) to create a new package from scratch, aiming to use git, salsa, salsa-ci, gbp and DEP14 from the beginning?
Once found I think it would be useful to have it well documented, in a unified part and to which new arrivals can point (and also mentors use and point to it).
There are people with enough experience with git, good intuition and who learn easily and fast, but as I have noticed there are also people who have no or almost no experience with git and have difficulty learning new things.
An example is a new maintainer that I helped a lot to packaging his software for Debian, at the beginning he tried alone, he arrived on mentors but despite some attempts for a long time he continued only with unofficial packages that he created in a simple and fast way.
I explained to him about the packaging itself and then given the many difficulties in making him learn the necessary things for git and package management I thought it was better to avoid complicating further with external packaging on salsa but to do it on a branch of the upstream repository on github (with gbp import-ref) and now he has managed to prepare the latest versions by himself or almost.
In some cases like that it might be better to host the packages outside of salsa but for the major cases having a detailed, simple, fast and unique documentation to aim to use git, salsa and salsa-ci from the beginning I think would be useful. Using salsa-ci from the beginning can help to have some first tests also in a simpler and faster way rather than making local environments for clean builds on Sid and also all the various necessary checks, those can be done shortly later, so as not to overload the new people with too many tools, too many procedures etc... they will already be loaded by the packaging itself in a complete way and following the policies and then there are parts like for example the complete and correct creation of debian/copyright that could even take more time than all the rest of the packaging in some cases (but this is another thing).
I don't know if I've managed to explain well what I mean, but from what I've seen over the years, most of the people I've seen trying to approach packaging have had difficulty finding documentation and help (even on mentors, although it seems to have improved recently), but I haven't had time to follow people, I've mostly made some occasional messages and tried to follow a few people specifically (unfortunately I haven't had enough time either). What I seem to have noticed (I could also be wrong) is that most people "run away" at the beginning or after a while due to the difficulty in finding all the necessary information and/or too much time spent on basic packaging following the policies and complete and correct d/copyright. Others, on the other hand, seem to have left due to too much time spent waiting for someone that revision the package or finding sponsors that can upload it (but this would also be another thing outside the point of this topic).
OpenPGP_signature.asc
Description: OpenPGP digital signature
