r87 - /web/deps/dep1.html

Fri Aug 7 12:56:35 UTC 2009

Author: zack
Date: Fri Aug  7 12:56:35 2009
New Revision: 87

URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=87
Log:
add DEP1 (accepted) to the repository: it is frozen now

Added:
    web/deps/dep1.html

Added: web/deps/dep1.html
URL: http://svn.debian.org/wsvn/dep/web/deps/dep1.html?rev=87&op=file
==============================================================================

--- web/deps/dep1.html (added)
+++ web/deps/dep1.html Fri Aug  7 12:56:35 2009
@@ -1,0 +1,85 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+<link rel="shortcut icon" href="/htdocs/favicon.ico">
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+<meta name="robots" content="noindex,nofollow">
+
+<title>NmuDep - Debian Wiki</title>
+<script type="text/javascript" src="/htdocs/common/js/common.js"></script>
+
+
+<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/htdocs/modern/css/common.css">
+<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/htdocs/modern/css/print.css">
+<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/htdocs/debian-wiki-1.0.css">
+
+<!-- css only for MSIE browsers -->
+<!--[if IE]>
+   <link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/htdocs/modern/css/msie.css">
+<![endif]-->
+
+
+</head>
+
+<body  lang="en" dir="ltr">
+<div id="page" lang="en" dir="ltr">
+
+<div dir="ltr" id="content" lang="en"><span class="anchor" id="top"></span>
+<span class="anchor" id="line-1"></span><p class="line867"><span class="anchor" id="line-2"></span><span class="anchor" id="line-3"></span><span class="anchor" id="line-4"></span><span class="anchor" id="line-5"></span><span class="anchor" id="line-6"></span><span class="anchor" id="line-7"></span><span class="anchor" id="line-8"></span><span class="anchor" id="line-9"></span><span class="anchor" id="line-10"></span><span class="anchor" id="line-11"></span><span class="anchor" id="line-12"></span><pre>Title: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
+DEP: 1
+State: ACCEPTED
+Date: 2008-02-12
+Drivers: Lucas Nussbaum &lt;lucas at debian.org&gt;,
+ Bas Wijnen &lt;wijnen at debian.org&gt;
+URL: http://wiki.debian.org/NmuDep
+Abstract:
+ This document aims at clarifying the policies and workflows used for NMUs
+ inside Debian. Its main goal is to provide a patch to section 5.11 of the
+ Debian Developer's Reference, adressing the current issues regarding NMUs.</pre><span class="anchor" id="line-13"></span><p class="line867">
+<h1 id="IntroductionandMotivation">Introduction and Motivation</h1>
+<span class="anchor" id="line-14"></span><p class="line874">In Debian, each package is "owned" by its maintainer, or by a small group of maintainers, in the case of team maintenance. Modifying the package requires going through those developers, which sometimes add a long, unnecessary delay, especially in the case of inactive or busy maintainers. <span class="anchor" id="line-15"></span><span class="anchor" id="line-16"></span><p class="line874">Non-maintainer uploads (NMUs) alleviate this problem, by allowing any developer to upload a new version of another maintainer's package. However, the current rules for NMUs are not very clear, so: <span class="anchor" id="line-17"></span><span class="anchor" id="line-18"></span><ol type="1"><li>many developers prefer not to do NMUs. <span class="anchor" id="line-19"></span></li><li>different developers understand the rules differently, leading to different opinions on what's allowed or not. <span class="anchor" id="line-20"></span></li><li>NMUs are often received with angry comments from maintainers. <span class="anchor" id="line-21"></span></li></ol><p class="line874">This Debian Enhancement Proposal has two goals: <span class="anchor" id="line-22"></span><span class="anchor" id="line-23"></span><ol type="1"><li>improve section 5.11 of the Developer's Reference, to clarify it and address the current issues about NMUs. In particular: <span class="anchor" id="line-24"></span><ol type="1"><li>We explicitely allow fixing bugs of severity lower than important in NMUs <span class="anchor" id="line-25"></span></li><li>We encourage the use of the DELAYED queue <span class="anchor" id="line-26"></span></li><li>We try to encourage a responsible approach for NMUs, instead of an approach based on strict rules <span class="anchor" id="line-27"></span></li></ol></li><li>improve related tools, like the nmudiff script in the devscripts package. <span class="anchor" id="line-28"></span></li></ol><p class="line867">
+<h1 id="Proposedsection5.11.3ANon-MaintainerUploads.28NMUs.29">Proposed section 5.11: Non-Maintainer Uploads (NMUs)</h1>
+<span class="anchor" id="line-29"></span><span class="anchor" id="line-30"></span><p class="line874">Every package has one or more maintainers. Normally, these are the people who work on and upload new versions of the package. In some situations, it is useful that other developers can upload a new version as well, for example if they want to fix a bug in a package they don't maintain, when the maintainer fails to respond to issues.  Such uploads are called Non-Maintainer Uploads (NMU). <span class="anchor" id="line-31"></span><span class="anchor" id="line-32"></span><p class="line867">
+<h2 id="A5.11.1WhenandhowtodoanNMU">5.11.1 When and how to do an NMU</h2>
+<span class="anchor" id="line-33"></span><span class="anchor" id="line-34"></span><p class="line874">Before doing an NMU, consider the following questions: <span class="anchor" id="line-35"></span><span class="anchor" id="line-36"></span><ul><li>Do you really fix bugs in your NMU? Fixing cosmetic issues, or changing the packaging style in NMUs is discouraged, unless it is required to fix bugs. <span class="anchor" id="line-37"></span></li><li>Did you give enough time to the maintainer? When was the bug reported to the BTS? Being busy for a week or two isn't unusual.  Is the bug so severe that it needs to be fixed right now, or can it wait a few more days? <span class="anchor" id="line-38"></span></li><li>How confident are you about your changes? Please remember the Hippocratic Oath: "Above all, do no harm." It is better to leave a package with an open grave bug than applying a non-functional patch, or one that hides the bug instead of resolving it. If you are not 100% sure of what you did, it might be a good idea to seek advice from others. Remember that if you break something in your NMU, many people will be very unhappy about it. <span class="anchor" id="line-39"></span></li><li>Have you clearly expressed your intention to NMU, at least on the BTS? Has the maintainer been notified of it? It is also a good idea to try to contact the maintainer by other means (private email, IRC) <span class="anchor" id="line-40"></span></li><li>If the maintainer is usually active and responsive, have you tried to contact him? In general it should be considered preferable that a maintainer takes care of an issue himself and that he is given the chance to review and correct your patch, because he can be expected to be more aware of potential issues which an NMUer might miss. <span class="anchor" id="line-41"></span><span class="anchor" id="line-42"></span></li></ul><p class="line874">When doing an NMU, you must first make sure that your intention to NMU is really clear.  Then, you must send a patch with the differences between the current package and your proposed NMU to the BTS. <span class="anchor" id="line-43"></span><span class="anchor" id="line-44"></span><p class="line874">Unless you have an excellent reason not to do so, you must then give some time to the maintainer to react (for example, by uploading to the DELAYED queue). Here are some delays that you could use as default values: <span class="anchor" id="line-45"></span><span class="anchor" id="line-46"></span><ul><li>Upload fixing only release-critical bugs older than 7 days: 2 days <span class="anchor" id="line-47"></span></li><li>Upload fixing only release-critical and important bugs: 5 days <span class="anchor" id="line-48"></span></li><li>Other NMUs: 10 days <span class="anchor" id="line-49"></span><span class="anchor" id="line-50"></span></li></ul><p class="line874">Those delays are only examples. In some cases (uploads fixing security issues, trivial bugfixes blocking a transition, ...), it is desirable that the fixed package reaches unstable sooner. <span class="anchor" id="line-51"></span><span class="anchor" id="line-52"></span><p class="line862">Sometimes, release managers decide to allow NMUs with shorter delays for a subset a bugs (e.g release critical bugs older than 7 days). Also, some maintainers listed themselves in the <a class="http" href="http://wiki.debian.org/LowThresholdNmu">Low Threshold NMU list</a>, and accept that NMUs are uploaded without delay. But even in those cases, it's still a good idea to give the maintainer a few days to react before you upload, especially if the patch wasn't available on the BTS before, or if you know that the maintainer is generally active. <span class="anchor" id="line-53"></span><span class="anchor" id="line-54"></span><p class="line874">After you upload an NMU, you are responsible for the possible problems that you might have introduced. You must keep an eye on the package (subscribing to the package on the PTS is a good idea). <span class="anchor" id="line-55"></span><span class="anchor" id="line-56"></span><p class="line874">This is not a license to perform NMUs thoughtlessly.  If you NMU when it is clear that the maintainers are active and would have acknowledged a patch in a timely manner, or if you ignore the recommendations of this document, be warned, there is no protection for you here.  You should always be prepared to defend the wisdom of any NMU you perform on its own merits. <span class="anchor" id="line-57"></span><span class="anchor" id="line-58"></span><p class="line867">
+<h3 id="A5.11.1.1NMUsanddebian.2BAC8-changelog">5.11.1.1 NMUs and debian/changelog</h3>
+<span class="anchor" id="line-59"></span><p class="line874">Just like any other (source) upload, NMUs must add an entry to debian/changelog, telling what has changed with this upload.  The first line of this entry is special, it must be <span class="anchor" id="line-60"></span><span class="anchor" id="line-61"></span><p class="line867"><tt>&nbsp;*&nbsp;Non-maintainer&nbsp;upload.</tt> <span class="anchor" id="line-62"></span><span class="anchor" id="line-63"></span><p class="line862">The version must be the version of the last upload, plus <strong>+nmuX</strong>, where <strong>X</strong> is a counter starting at <strong>1</strong>.  If the last upload was also an NMU, the counter should be increased.  For example, if the current version is <strong>1.5-1</strong>, then an NMU would get version <strong>1.5-1+nmu1</strong>.  If the current version is <strong>1.5+nmu3</strong> (a native package which has already been NMUd), the NMU would get version <strong>1.5+nmu4</strong>.  If a new upstream version is packaged in the NMU, the debian revision is set to <strong>0</strong>, for example <strong>1.6-0+nmu1</strong>. <span class="anchor" id="line-64"></span><span class="anchor" id="line-65"></span><p class="line874">This special versioning is needed to avoid stealing one of the package maintainer's version numbers, which might disrupt their work. It also has the benefit of making it visually clear that a package in the archive was not made by the official maintainer. <span class="anchor" id="line-66"></span><span class="anchor" id="line-67"></span><p class="line862">If you upload a package to testing or stable, you sometimes need to "fork" the version number tree. This is the case for security uploads, for example.  For this, a version of the form <strong>+debXYuZ</strong> should be used, where <strong>X</strong> is the current stable major release number, and <strong>Y</strong> is the current minor release number for a stable upload, or one higher than that for a testing upload. <strong>Z</strong> is a counter starting at <strong>1</strong>.  For example, while Etch (Debian 4.0) is stable, a security NMU to stable for a package at version <strong>1.5-3</strong> would have version <strong>1.5-3+deb40u1</strong>, while a security NMU to Lenny would get version <strong>1.5-3+deb41u1</strong>.  This is the case <strong>even when it is already known that the next release will be a new major version</strong>; for instance, Lenny will be released as Debian 5.0. <span class="anchor" id="line-68"></span><span class="anchor" id="line-69"></span><p class="line867">
+<h3 id="A5.11.1.2UsingtheDELAYED.2BAC8queue">5.11.1.2 Using the DELAYED/ queue</h3>
+<span class="anchor" id="line-70"></span><p class="line874">After asking the maintainer for the permission to upload your NMU, it is annoying to have to wait for some time before you actually make the upload. <span class="anchor" id="line-71"></span><span class="anchor" id="line-72"></span><p class="line874">The DELAYED queue (FIXME: link to 5.6.2) allows the developer doing the NMU to perform all the necessary tasks at the same time. Instead of telling the maintainer that you will upload the updated package in (for example) 7 days, you should upload the package to DELAYED/7 and tell the maintainer that he has 7 days to react.  During this time, the maintainer can ask you to delay the upload some more or cancel your upload. <span class="anchor" id="line-73"></span><span class="anchor" id="line-74"></span><p class="line874">The DELAYED queue should not be used to put additional pressure on the maintainer. In particular, it's important that you are available to cancel or delay the upload before the delay expires (the maintainer cannot cancel the upload himself). <span class="anchor" id="line-75"></span><span class="anchor" id="line-76"></span><p class="line874">If you make an NMU to DELAYED, and the maintainer updates his package before the delay expires, your upload will be rejected, because a newer version (the maintainer's one) is already available in the archive.  Normally, the maintainer should take care to include your proposed changes (or at least a solution for the problems they address) in that upload. <span class="anchor" id="line-77"></span><span class="anchor" id="line-78"></span><p class="line867">
+<h2 id="A5.11.2NMUs.2Cfromthemaintainer.27spointofview">5.11.2 NMUs, from the maintainer's point of view</h2>
+<span class="anchor" id="line-79"></span><p class="line874">When someone NMUs your package, this means they want to help you to keep it in good shape.  This saves you work, and gives users fixed packages faster.  You can consider asking the NMUer to become a co-maintainer of the package. <span class="anchor" id="line-80"></span><span class="anchor" id="line-81"></span><p class="line874">If someone suggests that they could do an NMU on your package, you should be thankful that they want to put time into this, while it is really your responsibility to fix the bug.  Receiving an NMU on a package is not a bad thing; it just means that the package is interesting enough for other people to work on it. <span class="anchor" id="line-82"></span><span class="anchor" id="line-83"></span><p class="line874">When a package has been NMUed, the maintainer should acknowledge it in the next upload.  This makes clear that the changes were accepted <span class="anchor" id="line-84"></span>in the maintainer's packaging, and that they aren't lost again.  For this, you must first incorporate the changes into your package, as far <span class="anchor" id="line-85"></span>as you want to keep them.  Make sure to include the NMU's changelog entry (not just the line describing the changes) in your own changelog. <span class="anchor" id="line-86"></span>This is important to allow the BTS version tracking to work. <span class="anchor" id="line-87"></span><span class="anchor" id="line-88"></span><p class="line867">
+<h2 id="A5.11.3SourceNMUsvsBinary-onlyNMUs.28binNMUs.29">5.11.3 Source NMUs vs Binary-only NMUs (binNMUs)</h2>
+<span class="anchor" id="line-89"></span><p class="line862">The full name of an NMU is <em>source NMU</em>.  There is also another type, namely the <em>binary-only NMU</em>, or <em>binNMU</em>.  A binNMU is also a package upload by someone other than the package's maintainer.  However, it is a binary-only upload. <span class="anchor" id="line-90"></span><span class="anchor" id="line-91"></span><p class="line874">When a library (or other dependency) is updated, the packages using it may need to be rebuilt.  Since no changes to the source are needed, the same source package is used. <span class="anchor" id="line-92"></span><span class="anchor" id="line-93"></span><p class="line874">BinNMUs are usually done by porters.  They add an entry to debian/changelog, explaining why the upload was needed and increasing the version number as described in paragraph 5.10.2.1.  This entry should not be included in the next upload. <span class="anchor" id="line-94"></span><span class="anchor" id="line-95"></span><p class="line874">Buildds upload packages for their architecture to the archive as binary-only uploads.  Strictly speaking, these are binNMUs.  However, they are not normally called NMU, and they don't add an entry to debian/changelog. <span class="anchor" id="line-96"></span><span class="anchor" id="line-97"></span><p class="line867">
+<h2 id="A5.11.4NMUsvsQAuploads">5.11.4 NMUs vs QA uploads</h2>
+<span class="anchor" id="line-98"></span><p class="line874">NMUs are uploads of packages which are owned by another maintainer.  There is another type of upload where the uploaded package is not yours: QA uploads. QA uploads are uploads of orphaned packages. <span class="anchor" id="line-99"></span><span class="anchor" id="line-100"></span><p class="line874">QA uploads are very much like normal maintainer uploads: they may fix anything, even minor issues; the version numbering is normal, and there is no need to use a delayed upload.  The difference is that you are not listed as the Maintainer or Uploader for the package.  Also, the changelog entry of a QA upload has a special first line: <span class="anchor" id="line-101"></span><span class="anchor" id="line-102"></span><p class="line867"><tt>&nbsp;*&nbsp;QA&nbsp;upload.</tt> <span class="anchor" id="line-103"></span><span class="anchor" id="line-104"></span><p class="line862">If you want to do an NMU, and it seems that the maintainer is not active, it is wise to check if the package is orphaned.  When doing the first QA upload to an orphaned package, the maintainer should be set to <em>Debian QA Group &lt; <a class="mailto" href="mailto:packages at qa.debian.org">packages at qa.debian.org</a> &gt;</em>.  Orphaned packages which did not have a QA upload yet still have their old maintainer set.  There is a list of them at <a class="http" href="http://qa.debian.org/orphaned.html">http://qa.debian.org/orphaned.html</a>. <span class="anchor" id="line-105"></span><span class="anchor" id="line-106"></span><p class="line862">Instead of doing a QA upload, you can also consider adopting the package by making yourself the maintainer.  You don't need permission from anybody to adopt an orphaned package, you can just set yourself as maintainer and upload the new version (<a class="http" href="http://www.debian.org/doc/developers-reference/pkgs.html#adopting">details here</a>). <span class="anchor" id="line-107"></span><span class="anchor" id="line-108"></span><p class="line867">
+<h1 id="nmudiffimprovements">nmudiff improvements</h1>
+<span class="anchor" id="line-109"></span><p class="line874">Currently, nmudiff uses the following default email: <span class="anchor" id="line-110"></span><span class="anchor" id="line-111"></span><p class="line867"><span class="anchor" id="line-112"></span><span class="anchor" id="line-113"></span><span class="anchor" id="line-114"></span><pre>Hi,
+The following is the diff for my $SOURCE $VERSION NMU.</pre><span class="anchor" id="line-115"></span><p class="line874">It is proposed that this will be changed to: <span class="anchor" id="line-116"></span><span class="anchor" id="line-117"></span><p class="line867"><span class="anchor" id="line-118"></span><span class="anchor" id="line-119"></span><span class="anchor" id="line-120"></span><span class="anchor" id="line-121"></span><span class="anchor" id="line-122"></span><span class="anchor" id="line-123"></span><span class="anchor" id="line-124"></span><pre>[Replace XX with correct value]
+Dear maintainer,
+I prepared an NMU for $SOURCE (versioned as $VERSION) to fix this bug.
+I uploaded it to DELAYED/XX. Please feel free to tell me if I should delay it longer.
+--
+$DEBFULLNAME</pre><span class="anchor" id="line-125"></span><p class="line867">
+<h1 id="Rationales">Rationales</h1>
+<span class="anchor" id="line-126"></span><span class="anchor" id="line-127"></span><p class="line867">
+<h2 id="Directcommitusingdebcheckout">Direct commit using debcheckout</h2>
+<span class="anchor" id="line-128"></span><span class="anchor" id="line-129"></span><p class="line874">In some cases, the maintainer might allow direct commit to the package's VCS repository. We felt that it was not a good idea to include this in the DEP, because: <span class="anchor" id="line-130"></span><ul><li>there's currently no way for the maintainer to say whether he wants NMUers to commit their changes or not <span class="anchor" id="line-131"></span></li><li>this practice is not in widespread use, as far as we know <span class="anchor" id="line-132"></span></li><li>debcheckout isn't documented elsewhere in developer-reference <span class="anchor" id="line-133"></span><span class="anchor" id="line-134"></span></li></ul><p class="line867">
+<h2 id="thenmudiffpatchisnotcontroversial.WhyincludeitintheDEP.3F">the nmudiff patch is not controversial. Why include it in the DEP?</h2>
+<span class="anchor" id="line-135"></span><span class="anchor" id="line-136"></span><ul><li>If the DEP isn't agreed upon, the patch has no reason to be included in devscripts. <span class="anchor" id="line-137"></span></li><li>It gives the opportunity to discuss the formulation at the same time as the rest of the DEP. <span class="anchor" id="line-138"></span></li><li><p class="line862">DEPs are supposed to allow changes in several parts of Debian at the same time. That's a good test case <img alt=":-)" height="15" src="/htdocs/modern/img/smile.png" title=":-)" width="15" /> <span class="anchor" id="line-139"></span><span class="anchor" id="line-140"></span></li></ul><p class="line867">
+<h2 id="Isthatreallythebestplacetodiscussstable.2CsecurityandQAuploads.2CandbinNMUs.3F">Is that really the best place to discuss stable, security and QA uploads, and binNMUs?</h2>
+<span class="anchor" id="line-141"></span><ul><li>It's there in the current version of this chapter. <span class="anchor" id="line-142"></span></li><li>Reorganisation of developer-reference is probably a job for the developer-reference's maintainer, not for us. <span class="anchor" id="line-143"></span><span class="anchor" id="line-144"></span></li></ul><p class="line867">
+<h1 id="History">History</h1>
+<span class="anchor" id="line-145"></span><span class="anchor" id="line-146"></span><p class="line874">Cosmetic changes are not mentioned here, refer to the wiki page's history if you need them. <span class="anchor" id="line-147"></span><span class="anchor" id="line-148"></span><p class="line867">
+<h2 id="A2008-06-03">2008-06-03</h2>
+<span class="anchor" id="line-149"></span><ul><li>Reworked heavily section 5.11.1, after discussion on debian-project at . <span class="anchor" id="line-150"></span><span class="anchor" id="line-151"></span></li></ul><p class="line867">
+<h2 id="A2008-05-29">2008-05-29</h2>
+<span class="anchor" id="line-152"></span><ul><li>Clarified NMU acknowledging a bit. <span class="anchor" id="line-153"></span></li><li>Emphasize that the NMUer is responsible for the breakage he introduced. <span class="anchor" id="line-154"></span><span class="anchor" id="line-155"></span></li></ul><p class="line867">
+<h2 id="A2008-04-28">2008-04-28</h2>
+<span class="anchor" id="line-156"></span><ul><li>Emphasize that example values are examples, and that it's sometimes desirable to upload sooner. <span class="anchor" id="line-157"></span><span class="anchor" id="line-158"></span></li></ul><p class="line867">
+<h2 id="A2008-04-23">2008-04-23</h2>
+<span class="anchor" id="line-159"></span><ul><li>Make NMU versioning match dch. <span class="anchor" id="line-160"></span></li><li>Make security versioning less confusing. <span class="anchor" id="line-161"></span></li><li>Don't confuse buildd uploads with binNMUs. <span class="anchor" id="line-162"></span></li><li>Explicitly require sending a patch to the BTS (and reporting the bug). <span class="anchor" id="line-163"></span></li><li>Don't talk about waiting, but instead specify the DELAYED queue as the only normal way to do an NMU. <span class="anchor" id="line-164"></span></li><li>Added rationale section. <span class="anchor" id="line-165"></span></li><li>Added rationale for "no mention of debcheckout" <span class="anchor" id="line-166"></span></li><li>Added rationale for inclusion of nmudiff patch. <span class="anchor" id="line-167"></span></li><li>Added "default values" for delays. <span class="anchor" id="line-168"></span></li><li>Improved introduction. <span class="anchor" id="line-169"></span></li></ul><span class="anchor" id="bottom"></span></div><p id="pageinfo" class="info" lang="en" dir="ltr">NmuDep  (last edited 2009-05-17 04:46:01 by <span title="FranklinPiat @ klabs.be[82.224.65.140]"><a href="/FranklinPiat" title="FranklinPiat @ klabs.be[82.224.65.140]">FranklinPiat</a></span>)</p>
+<div id="pagebottom"></div>
+</div>
+</body>
+</html>
+


