Hello everyone, I was surprised to see the reaction my comments generated and like Gianfranco, I also want to ask Marc to consider rethinking his decision. I do not think you are spoiling the fun or that insisting on oldfashioned keeping is a bad thing. I apologize that my choice of words made you feel that way - I am not a native english speaker either, so it may have sounded different than I intended.
I chose github as a mirror because I have upload rights there, that's the only reason. I would also prefer to work on *.debian.org and I will do so once I have permission. I just thought hosting git repo online somewhere makes looking at it easier than sending stuff by mail, and using github seemed like the easier choice than hosting and maintaining a git browser myself. Since git clones contain the entire history, switching mirrors shouldn't be complicated once upload permission is granted. I chose the "ignore upstream tarball/use git tag" method also just because it was simpler. Had I imported the release tarball, I would have had to maintain the list of files that are auto-generated (a simple *.c won't do, for example _chunker.c is handwritten), and add rules to remove them from the build dir or change their timestamp so that they get refreshed at build-time. Not having them in the first place made that unnecessary. That's the reason why upstream git tag seemed easier to create a working example implementation of the "regenerate files" idea. The git tag is gpg-signed with the same key as the tar.gz release, so I don't really see the difference in authenticity, please elaborate why .tar.gz would be superior for validation of borgbackup. From what I understand, an end-user will trust whatever checksum the Maintainer puts into .changes and signs with maintainer key, so this is just an issue of what the maintainer trusts. Or am I getting this wrong? - Danny