<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.214 $">
+ <!ENTITY cvs-rev "$Revision: 1.219 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
preparations you have to do before you can register to become a Debian
developer.
-For example, before you apply, you have to to read the <url
+For example, before you apply, you have to read the <url
id="&url-social-contract;" name="Debian Social Contract">.
Registering as a developer means that you agree with and pledge to
uphold the Debian Social Contract; it is very important that
<p>
The bug tracking system's features interesting to developers are described
in the <url id="&url-bts-devel;" name="BTS documentation for developers">.
-This includes closing bugs, sending followup messages, assigning severities,
-tags, marking bugs as forwarded and other issues.
+This includes closing bugs, sending followup messages, assigning severities
+and tags, marking bugs as forwarded and other issues.
<p>
Operations such as reassigning bugs to other packages, merging separate
bug reports about the same issue, or reopening bugs when they are
<file>debian/changelog</file>. For stable this is <tt>stable-security</tt> and for
testing this is <tt>testing-security</tt>, and for the previous
stable release, this is <tt>oldstable-security</tt>. Do not target
- <var>distribution</var>-proposed-updates!
+ <var>distribution</var>-proposed-updates or <tt>stable</tt>!
<item>Make descriptive, meaningful changelog entries. Others will
rely on them to determine whether a particular bug was fixed.
- Whenever possible, include an external reference, preferably a CVE
- identifier, so that it can be cross-referenced.
+ Always include an external reference, preferably a CVE
+ identifier, so that it can be cross-referenced. Include the same
+ information in the changelog for unstable, so that it is clear that
+ the same bug was fixed, as this is very helpful when verifying
+ that the bug is fixed in the next stable release. If a CVE
+ identifier has not yet been assigned, the security team will
+ request one so that it can be included in the package and in the advisory.
<item>Make sure the version number is proper. It must be greater
than the current package, but less than package versions in later
distributions. If in doubt, test it with <tt>dpkg
- --compare-versions</tt>. For <em>testing</em>, there must be
+ --compare-versions</tt>. Be careful not to re-use a version
+ number that you have already used for a previous upload. For
+ <em>testing</em>, there must be
a higher version in <em>unstable</em>. If there is none yet (for example,
if <em>testing</em> and <em>unstable</em> have the same version) you must upload a
new version to unstable first.
<p>
The following practices are relevant to the
<file>debian/control</file> file. They supplement the <url
-id="&url-debian-policy;ch-miscellaneous.html#s-descriptions"
+id="&url-debian-policy;ch-binary.html#s-descriptions"
name="Policy on package descriptions">.
<p>
The description of the package, as defined by the corresponding field
<example><var>package-name</var> are <var>synopsis</var>.</example>
-This way of forming a sentance from the package name and synopsis
+This way of forming a sentence from the package name and synopsis
should be considered as a heuristic and not a strict rule. There are
-some cases where it doesn't make sense to try to form a sentance.
+some cases where it doesn't make sense to try to form a sentence.
</sect1>
<sect1 id="bpp-pkg-desc">
~ianmdlvl / developers-reference.git / blobdiff