-msgstr ""
-
-# type: Content of: <chapter><section><para>
-#: pkgs.dbk:1763
-msgid ""
-"Under certain circumstances it is necessary for someone other than the "
-"official package maintainer to make a release of a package. This is called "
-"a non-maintainer upload, or NMU."
-msgstr ""
-
-# type: Content of: <chapter><section><para>
-#: pkgs.dbk:1768
-msgid ""
-"This section handles only source NMUs, i.e. NMUs which upload a new version "
-"of the package. For binary-only NMUs by porters or QA members, please see "
-"<xref linkend=\"binary-only-nmu\"/> . If a buildd builds and uploads a "
-"package, that too is strictly speaking a binary NMU. See <xref linkend="
-"\"buildd\"/> for some more information."
-msgstr ""
-
-# type: Content of: <chapter><section><para>
-#: pkgs.dbk:1775
-msgid ""
-"The main reason why NMUs are done is when a developer needs to fix another "
-"developer's package in order to address serious problems or crippling bugs "
-"or when the package maintainer is unable to release a fix in a timely "
-"fashion."
-msgstr ""
-
-# type: Content of: <chapter><section><para>
-#: pkgs.dbk:1780
-msgid ""
-"First and foremost, it is critical that NMU patches to source should be as "
-"non-disruptive as possible. Do not do housekeeping tasks, do not change the "
-"name of modules or files, do not move directories; in general, do not fix "
-"things which are not broken. Keep the patch as small as possible. If "
-"things bother you aesthetically, talk to the Debian maintainer, talk to the "
-"upstream maintainer, or submit a bug. However, aesthetic changes must "
-"<emphasis>not</emphasis> be made in a non-maintainer upload."
-msgstr ""
-
-# type: Content of: <chapter><section><para>
-#: pkgs.dbk:1789
-msgid ""
-"And 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."
-msgstr ""
-
-# type: Content of: <chapter><section><section><title>
-#: pkgs.dbk:1794
-msgid "How to do a NMU"
-msgstr "NMU のやり方"
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1796
-msgid ""
-"NMUs which fix important, serious or higher severity bugs are encouraged and "
-"accepted. You should endeavor to reach the current maintainer of the "
-"package; they might be just about to upload a fix for the problem, or have a "
-"better solution."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1802
-msgid ""
-"NMUs should be made to assist a package's maintainer in resolving bugs. "
-"Maintainers should be thankful for that help, and NMUers should respect the "
-"decisions of maintainers, and try to personally help the maintainer by their "
-"work."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1808
-msgid ""
-"A NMU should follow all conventions, written down in this section. For an "
-"upload to testing or unstable, this order of steps is recommended:"
-msgstr ""
-
-# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: pkgs.dbk:1814
-msgid ""
-"Make sure that the package's bugs that the NMU is meant to address are all "
-"filed in the Debian Bug Tracking System (BTS). If they are not, submit them "
-"immediately."
-msgstr ""
-
-# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: pkgs.dbk:1821
-msgid ""
-"Wait a few days for the response from the maintainer. If you don't get any "
-"response, you may want to help them by sending the patch that fixes the "
-"bug. Don't forget to tag the bug with the patch keyword."
-msgstr ""
-
-# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: pkgs.dbk:1828
-msgid ""
-"Wait a few more days. If you still haven't got an answer from the "
-"maintainer, send them a mail announcing your intent to NMU the package. "
-"Prepare an NMU as described in this section, and test it carefully on your "
-"machine (cf. <xref linkend=\"sanitycheck\"/> ). Double check that your "
-"patch doesn't have any unexpected side effects. Make sure your patch is as "
-"small and as non-disruptive as it can be."
-msgstr ""
-
-# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: pkgs.dbk:1838
-msgid ""
-"Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. "
-"<xref linkend=\"delayed-incoming\"/> ), send the final patch to the "
-"maintainer via the BTS, and explain to them that they have 7 days to react "
-"if they want to cancel the NMU."
-msgstr ""
-
-# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: pkgs.dbk:1846
-msgid ""
-"Follow what happens, you're responsible for any bug that you introduced with "
-"your NMU. You should probably use <xref linkend=\"pkg-tracking-system\"/> "
-"(PTS) to stay informed of the state of the package after your NMU."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1853
-msgid ""
-"At times, the release manager or an organized group of developers can "
-"announce a certain period of time in which the NMU rules are relaxed. This "
-"usually involves shortening the period during which one is to wait before "
-"uploading the fixes, and shortening the DELAYED period. It is important to "
-"notice that even in these so-called bug squashing party times, the NMU'er "
-"has to file bugs and contact the developer first, and act later. Please see "
-"<xref linkend=\"qa-bsp\"/> for details."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1862
-msgid ""
-"For the testing distribution, the rules may be changed by the release "
-"managers. Please take additional care, and acknowledge that the usual way "
-"for a package to enter testing is through unstable."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1867
-msgid ""
-"For the stable distribution, please take extra care. Of course, the release "
-"managers may also change the rules here. Please verify before you upload "
-"that all your changes are OK for inclusion into the next stable release by "
-"the release manager."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1873
-msgid ""
-"When a security bug is detected, the security team may do an NMU, using "
-"their own rules. Please refer to <xref linkend=\"bug-security\"/> for more "
-"information."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1878
-msgid ""
-"For the differences for Porters NMUs, please see <xref linkend=\"source-nmu-"
-"when-porter\"/> ."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1882
-msgid ""
-"Of course, it is always possible to agree on special rules with a maintainer "
-"(like the maintainer asking please upload this fix directly for me, and no "
-"diff required)."
-msgstr ""
-
-# type: Content of: <chapter><section><section><title>
-#: pkgs.dbk:1889
-msgid "NMU version numbering"
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1891
-msgid ""
-"Whenever you have made a change to a package, no matter how trivial, the "
-"version number needs to change. This enables our packing system to function."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1895
-msgid ""
-"If you are doing a non-maintainer upload (NMU), you should add a new minor "
-"version number to the <replaceable>debian-revision</replaceable> part of the "
-"version number (the portion after the last hyphen). This extra minor number "
-"will start at `1'. For example, consider the package `foo', which is at "
-"version 1.1-3. In the archive, the source package control file would be "
-"<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the "
-"Debian revision is `3'. The next NMU would add a new minor number `.1' to "
-"the Debian revision; the new source control file would be <filename>foo_1.1-"
-"3.1.dsc</filename>."
-msgstr ""
-
-# type: Content of: <chapter><section><section><para>
-#: pkgs.dbk:1906
-msgid ""
-"The Debian revision minor number 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."
-msgstr ""
~ianmdlvl / developers-reference.git / blobdiff