On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote: >Here's the draft: Thanks for getting this started. I think it will help considerably to get some standardization here. I would think that as more teams adopt git, they will eventually just refer to DEP 14, perhaps with some additional team-based deviations if necessary. One question: when this gets adopted, will individual maintainers or teams have to know which of the git packaging helpers a particular repository is using? IOW, what happens if I were to use gbp-pq on a package that someone else had used git-dpm on? Do we need some kind of convention to detect which helper is being used? I wouldn't want to restrict choice by defining a standard Debian-wide (but it's okay within the context of a team). I just want someone who walks up to a git repo to at least easily know which tools to use. >Vendor namespaces >----------------- > >Each "vendor" uses its own namespace for its packaging related >Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and >so on. My question is whether the vendor namespaces are overkill for the majority of packages, where there probably will be just one vendor (i.e. Debian). Should DEP 14 allow for a simplified layout such as master, pristine-tar, upstream when there is no other vendor involved? Allowing for master as an alternative to debian/sid or debian/master might simplify the common case. However, I'll also note that for pycurl, I'm currently using master to be the Debian unstable branch, and ubuntu to be a small set of deltas on top of that, for the current Ubuntu development series. If I needed to support older releases in either distro, then debian/wheezy or ubuntu/utopic would be good branches to use. (Or IOW, what's the equivalent of debian/sid for Ubuntu?) > QUESTION: some people have argued to use debian/master as the latest > packaging targets sometimes sid and sometimes experimental. Should we > standardize on this? Or should we explicitly allow this as an alternative? It makes some sense to allow this as an alternative, but then my question about using 'master' as an even simpler alternative for the common case should also be asked. >When releasing a Debian package, the packager should create and push >a signed tag named `<vendor>/<version>`. For example, a Debian maintainer >releasing a package with version 2:1.2~rc1-1 would create a tag named >`debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with >version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should >point to the exact commit that was used to build the corresponding upload. Agreed. Tag namespaces certainly make a lot of sense. >If the Git workflow in use imports the upstream sources from released >tarballs, this should be done under the "upstream" namespace. By default, >the latest upstream version should be imported in the `upstream/latest` >branch and when packages for multiple upstream versions are maintained >concurrently, one should create as many upstream branches as required. Similarly, is 'upstream' okay for the upstream branch? It's a little simpler than upstream/latest, especially if you don't anticipate importing an other upstream branches. Again thanks. After Jessie is released, I hope to restart this discussion over in Debian Python, for that team's transition to git. Cheers, -Barry
Attachment:
signature.asc
Description: PGP signature