I would like to point out some considerations. A winning approach for me is:
* don't assume that if I maintain packages in git, upstream is also developing using git. * don't assume that upstream is making releases. Maybe they don't make tarballs, even tags. Maybe they do, but they are very wrong (for example, bad versioning). * don't assume tarballs contains exactly the same as the git repo source. * don't try to have a standard to fit all upstream projects and/or DDs likes. Having a way to generate the upstream tarball in the own pkg git repo is a nice way to speed the packaging workflow. I guess the DEP can include the pristine-tar case and others as well, for example using git archive. This seems the weakest point at the moment. I think some of the key points in the standarization is about the style and good practices, for example: * commit messages with single line title + full description. No more than 80 characters per line. * signed-off-by lines and friends in commit messages, as in the Linux Kernel. * package should be able to build between commits. This is, the repo remains in a consistent state from commit to commit. * tagging layout. * when and how to update the changelog, using git-dch, etc.. IMHO, if Debian can provide a good standard (at least regarding style and good practices), we are all winning. regards. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOkSjBjyMJj7r5X4LVWR=jbPtfQzww2e=6pgd2hdv1ljexz...@mail.gmail.com
