Hi, > > and you seem to think adding another Debian specific complex tool will > > attrack new people? Most people^wcontributors out there know git already, > > for them a simple git only workflow is *much* more inviting than having > > to learn gbp *only* to contribute to Debian. > > This. Exactly this. > > This is the reason I can contribute small improvements to Alpine and > other projects with reasonable effort for small improvements. The > tools are the same tools I already use elsewhere, and stuff is as > transparent as it needs to be for outside contributors. > > Time to get build people where they are, and not where we are.
As Andrey wrote, sure this would be better, but also impossible. How .dsc/.deb/.orig.tar.gz and occasional modified .tar.gz work in Debian is fundamentally very different from how in e.g. Alpine a single APKBUILD defines a the upstream source a just an URL and a sha512 to verify the download was correct. Maybe one day in the future we change the Debian source format to not have upstream tarball bundled, but that is a totally different discussion from what we are doing now in DEP-18: recognizing the current most common workflows and elevating them as the recommended baseline for those who are keen to collaborate more efficiently. In Debian/DEP-18 for all the normal daily packaging work like pulling and pushing, making commits, amending commits, creating branches, rebasing branches etc you can and should use just regular git commits. Git-buildpackage is there only to tell people that is the tool to interact with repos. Git-buildpackage does what it does out of necessity to be able to produce the *.changes and *.dsc files. Therefore the upstream import and building packages need to be done in a certain way and there are 2 or 3 branches in the git repositories. Luckily, these 3 branch names are unified to be debian/latest, upstream/latest and pristine-tar thanks to DEP-14. Now with DEP-18 we can move along and make it easier for new people and also tenured maintainers to land on the same best practices. Going back to the example of Alpine, they enforce heavily one single workflow that includes one single VCS (git), one single hosting place (https://gitlab.alpinelinux.org/) and to my knowledge also one single tool to build and update packages. DEP-18 does not enforce anything, but if you want to have a situation that people voluntarily move towards adopting the same base workflow for undifferentiated Debian packaging, you should support DEP-18 and not dismiss it.
