Le Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog a écrit : > > while git is the most popular VCS for packaging, there's no clear rules > on what you can expect in a random git packaging repository listed > in Vcs-Git. I would like to fix this so that: > - we can extract more useful data from the git repositories > - we can more easily share our git repositories with upstreams > and downstreams > - we start to converge on some conventions even though we might > continue to use different git helper tools > > I want to use the DEP process for this. But before I can write a first > draft I would like to have your ideas of what we should include > in such a document.
Bonjour Raphaël, I think that it is a good idea to propose a standard that packaging team and individual developers can follow optionally if they like it. In the Debian Med packaging team, I would be glad to be able to replace the guidelines in our group with a pointer to the DEP that you propose to write. Here are a few comments. Regarding the name of the branches, I think that it would be preferable to systematically use a prefix, ‘debian’, and I think that ‘debian/unstable’ is more consistent than ‘debian/master’. For the backports, I have been using ‘debian/wheezy-backports’, etc. Altogether, the pattern is ‘debian/suite’. The ‘pristine-tar’ branch, while mostly used for Debian, is universal in principle (who would knowingly release a tarball with the same name and a different content from an alreadly circulating tarball ?), and therefore probably does not need a ‘debian’ prefix. Pristine-tar has been useful to avoid preparing an upload with a tarball that has the same content but a different MD5 sum than the one in the archive (because of time stamps, etc). The interest for this is a bit reduced now that we have source-only uploads (which are easier to prepare), but I think that it is still a good thing to have for source packages based on upstream tarballs. The ‘upstream’ branch generated and used by the tools from ‘git-buildpackage’ is usually different from the master branch of the upstream Git repository when it exists. While this branch name is well-established in Debian, I think that it is misleading and for my new packages I try to avoid it. When it is still necessary to import upstream tarballs, I would rather use a name under the ‘debian/’ prefix. When the upstream master branch is enough, I prefer to leave it under the name ‘master’. Of course, the Debian clones of the repository should use a debian branch by default, like ‘debian/unstable’. For the Debian tags, I think that we definitely need a prefix, as I have seen upstream releases like 1.0 being followed by 1.0-1… The tag prefix <debian> can be seen as identifying the distribution or the format; I would not mind if there were Ubuntu packages tagged with a <debian> prefix. The following is probably too rarely used to standardise, but maybe somebody has an insightful comment to make ? I have been storing build logs in the Git repositories of some source packages I maintain. At the beginning, I called the branch ‘meta‘ and had all the logs in the same branch, and later I tried things like debian/logs/unstable to separate suites, or build/amd64, etc, with one log in each branch, so that ‘git diff’ can do the right thing. Lastly, perhaps off-topic, would it make sense to give a recommendation on how to manage upstream sources that use Git and ‘gnulib’ ? I have met such a situation, where the version number of the program was not availalbe in any other way than through a Git tag, and could not find better than importing the release tarball with ‘git-import-orig’ instead of following Upstream's master branch. Have a nice week-end, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20140816045106.ga5...@falafel.plessy.net
