r328 - /web/deps/dep14.mdwn

Mon Jul 6 13:21:48 UTC 2015

Author: hertzog
Date: Mon Jul  6 13:21:48 2015
New Revision: 328

URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=328
Log:
Misc improvements following the last discussion

Modified:
    web/deps/dep14.mdwn

Modified: web/deps/dep14.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep14.mdwn?rev=328&op=diff
==============================================================================

--- web/deps/dep14.mdwn	(original)
+++ web/deps/dep14.mdwn	Mon Jul  6 13:21:48 2015
@@ -86,7 +86,8 @@
 or they can be permanent (in which case `<vendor>/master` should not
 exist).
 
-NOTE: The Git repository listed in debian/control's `Vcs-Git` field should
+NOTE: If the Git repository listed in debian/control's `Vcs-Git` field does
+not indicate an explicit branch (with the `-b <branch>` suffix) then it should
 have its HEAD point to the branch where new upstream versions are being
 packaged (that is one of the branches associated to a development release).
 The helper tools that do create those repositories should use a command
@@ -116,11 +117,12 @@
 ------------------------
 
 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.
+a (preferably 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.
 
 Managing upstream sources
 =========================
@@ -175,9 +177,8 @@
 Native packages
 ===============
 
-The above conventions mainly cater to the case of non-native packages,
-that is when the upstream developers and the package maintainers are
-not the same set of persons.
+The above conventions mainly cater to the case where the upstream
+developers and the package maintainers are not the same set of persons.
 
 When upstream is Debian (or one of its derivative), the upstream vendor
 should not use the usual `<vendor>/` prefix (but all others vendors should
@@ -185,17 +186,18 @@
 the codename of the target distribution (although you are free to still
 use the codename if you wish so).
 
-When the package is shipped as a native source package, the concept of
-"upstream sources" is irrelevant and the associated `upstream/*` branches
-are irrelevant too. Note that even if the upstream vendor ships the
-package as a native package, the downstream vendors can still can opt to
-package it in a non-native way.
+When the package is shipped as a native source package (i.e. a single
+tarball with no differentiation of the upstream sources and of the
+packaging files), the concept of "upstream sources" is irrelevant and the
+associated `upstream/*` branches are irrelevant too. Note that even if the
+upstream vendor ships the package as a native package, the downstream
+vendors can still can opt to package it in a non-native way.
 
 Patch queue tags
 ================
 
-A patch queue branch is a (temporary) branch used to define the set
-of upstream changes that the package will contain, its content is
+A patch queue branch is a (possibly temporary) branch used to define the
+set of upstream changes that the package will contain, its content is
 generally used to later update `debian/patches` in the resulting
 source package.
 
@@ -255,6 +257,19 @@
 this will make it much easier to merge between different packaging
 branches.
 
+When to not follow the above recommendations
+--------------------------------------------
+
+Most of the recommendations in this document assume that the upstream
+developers use their Git repository in a traditional way: one software per
+repository and creating tags for released versions.
+
+When the upstream diverge from those conventions, you are entitled
+to use your common sense and adapt those recommendations accordingly.
+For example, if upstream tags contain the software name (e.g.
+`foo-1.0` and `bar-2.0`), you should probably also consider embedding
+the name in the tags used for your package releases.
+
 Changes
 =======
 


