[SCM] Qt 4 Debian packaging. branch, master, updated. debian/4.5.2-2-4-g3dae7d1
Modestas Vainius
modax-guest at alioth.debian.org
Thu Oct 1 23:24:22 UTC 2009
The following commit has been merged in the master branch:
commit 3dae7d10ad2d895f68864aeb914a74506a7bd254
Author: Modestas Vainius <modestas at vainius.eu>
Date: Fri Oct 2 02:17:05 2009 +0300
First bits of debian/README.source: only policy for now.
Suggested workflow to follow in a couple of days. Feel free to comment.
---
debian/README.source | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 129 insertions(+), 0 deletions(-)
diff --git a/debian/README.source b/debian/README.source
new file mode 100644
index 0000000..ff9523b
--- /dev/null
+++ b/debian/README.source
@@ -0,0 +1,129 @@
+Patches to the original source code
+-----------------------------------
+
+Debian patches to the package original source must be stored in debian/patches
+directory. Debian patches are applied when the package is built and unapplied
+when the package is cleaned. The package uses quilt [1] for managing those
+patches. Various tasks of patch management (adding, removing etc.) are
+described in detail in /usr/share/doc/quilt/README.source (provided by quilt
+package of version 0.46-4.1 or later).
+
+Public VCS repository of Debian packaging
+-----------------------------------------
+
+Debian packaging history of this package is stored in Git [2] repository.
+Repository policy and packaging workflow are described below. This information
+is mostly for Debian package maintainers or people following packaging process.
+If you are merely preparing a NMU which changes upstream code, feel free to
+follow a standard patch creation procedure with quilt as described in the
+section above.
+
+Pushing permissions and occasional contributions
+------------------------------------------------
+
+* People in debian/control Maintainer and Uploaders (co-maintainers) fields may
+ freely push changes to public repository.
+* Other members of packaging group should request permission of current
+ co-maintainers (via IRC or mailing list) before adding yourself to the list of
+ Uploaders or pushing any other kind of changes.
+* Occasional contributors may send patches. Preferably, patches should be
+ formatted with `git format-patch` in order to maintain commit origin
+ information.
+* Pushed commits and patches must not violate repository policy as defined
+ below.
+
+Committing policy and guidelines
+--------------------------------
+
+* Work-in-progress debian/changelog entry must have its distribution field set to
+ UNRELEASED. That's DEBCHANGE_RELEASE_HEURISTIC=changelog setting for dch.
+* New packaging changes must be committed together with the change description
+ in the debian/changelog entry (if applicable). Sentences should end with dots.
+* The guidelines above are *highly* recommended to follow in order to reduce
+ conflicts in debian/changelog when cherry-picking and merging between
+ branches:
+ * Commits should be atomic (i.e. one change - one commit).
+ * It is a good idea to open a new revision with an empty changelog entry (two
+ empty lines between entry header and trailer) as its own commit. When
+ packaging a new upstream release, such first commit should include a new
+ changelog entry with "New upstream release." as the only change.
+ * dch should be configured with DEBCHANGE_MULTIMAINT_MERGE=yes or called with
+ --mainttrailer/-t option in order to reduce maintainer trailer changes.
+ As a result, dch --release should be used to update the date in the trailer
+ when releasing the package to Debian.
+* Commit message must be meaningful (typically, debchange is OK). The first
+ commit message line must be short (up to 72-80 characters) and end with a
+ dot. More detailed description might be provided in paragraphs wrapped at 80
+ characters after a empty line (e.g. like a well formatted standard Git commit
+ message).
+
+Branching policy
+----------------
+
+Debian packaging branches must not contain original source and must not have
+been merged with a branch containing original source code (referred by name
+"upstream" in the rest of this document) in any point of their history. If
+necessary, it is recommended to keep a private upstream branch in the private
+local repository or just track upstream remote Git repository locally.
+
+Debian packaging branches must only contain debian/ subdirectory in their root
+directory in order to avoid potential conflicts with upstream source. This
+restriction applies even to Git-specific files like .gitignore.
+
+Branches should be named as follows:
+
+ * master - main packaging branch. It typically contains packaging aimed at
+ unstable. However, if unstable is (semi-)frozen, it may even contain
+ packaging for experimental. It is up package maintainers what is considered
+ "current" release.
+ * Other mainline packaging branches must be named after Debian release
+ codenames (e.g. lenny, squeeze, sid, experimental etc.) that they contain
+ packaging of. When such a branch (e.g. experimental) is merged to master,
+ it does not need to be deleted from the remote repository.
+ * Other packaging "work" branches may be pushed to the remote repository at
+ discretion of package mantainer(s). These branches should be deleted from
+ the public repository when they are no longer needed.
+
+Non fast forwarding pushes (e.g. rebase of already published history) are
+forbidden to all mainline packaging branches unless they are absolutely
+necessary and have previously been agreed upon by co-maintainers of the
+package.
+
+Tagging policy
+--------------
+
+Tag namespace "debian" is reserved for tagging package releases to Debian.
+Preferably, public repository should not contain any other tags unless
+otherwise agreed upon.
+
+Each official package release must be tagged. The tag must meet the following
+requirements:
+
+ * The tag must mark the state of packaging as uploaded to Debian archive.
+ Re-tagging is allowed if necessary.
+ * The tag must be annotated and preferably signed with the key of uploader.
+ * The tag must be named like "debian/<version>" where <version> is a full
+ debian package version without epoch. All occurrences of the ~ character in
+ <version> should be replaced with the - character because Git does not
+ support ~ character in tag names.
+ * The tag must be assigned the message with content like
+ "<version>/<distribution>" where <version> is a full debian version of the
+ package (without any modifications including epoch) and <distribution>
+ is the distribution this package is uploaded to (as per the latest debian
+ changelog entry).
+
+For example, in order to tag the tip of current packaging branch as upload of
+the package version 4:4.6.0~beta1-1 to experimental, the following command may
+be used:
+
+ $ git tag debian/4.6.0-beta1-1 -sm "4:4.6.0~beta1-1/experimental"
+
+Suggested packaging workflows
+-----------------------------
+
+TODO
+
+
+[1] Available in the quilt package on Debian based systems. quilt must be
+ invoked with QUILT_PATCHES environment variables set to debian/patches.
+[2] Available in the git-core package on Debian based systems.
--
Qt 4 Debian packaging.
More information about the pkg-kde-commits
mailing list