← Back to branch summary

~ubuntu-branches/ubuntu/lucid/php-crypt-gpg/lucid

« back to all changes in this revision

Viewing changes to debian/NMU-Disclaimer

  • Committer: Bazaar Package Importer
  • Author(s): Joey Schulze
  • Date: 2008-12-26 20:37:24 UTC
  • Revision ID: james.westby@ubuntu.com-20081226203724-6itnk7b3f7y6myir
Tags: 1.0.0~RC1-1
* Initial packaging
* Improved rules file by dynamically importing dpatch snippets from dpatch
* Search for keys with passphrases not only for the particularly used
  subkey but also for the main key id in case the passphrase is stored
  under the main key id [01-not_only_subkeys.dpatch]
* Remove executable bit for patches on clean target

Show diffs side-by-side

added added

removed removed

Lines of Context:
debian/NMU-Disclaimer
 
1
Non Maintainer Upload of this Package
 
2
-------------------------------------
 
3
 
 
4
If you plan to work on an NMU for this package, read the following
 
5
closely.  It can save you and me some grief.
 
6
 
 
7
 1. At first, contact the maintainer (i.e. send a mail to
 
8
    joey@debian.org, do not cc or bounce a mail, send a plain mail,
 
9
    not copied to any mailing list or the BTS) and ask about the
 
10
    status of the bug you are considering to work on.
 
11
 
 
12
 2. In this mail include all information relevant for this problem,
 
13
    i.e. include a description of the bug and not only its bug
 
14
    number.
 
15
 
 
16
 3. If the maintainer is not able or willing to fix the problem or
 
17
    does not respond within four days, continue with step 4.
 
18
 
 
19
 4. Work on the bug and prepare a patch.  Do not upload into the
 
20
    Debian archive.
 
21
 
 
22
 5. Send the entire patch, together with enough explanations, to the
 
23
    maintainer for reviewing and ask him for permission of an NMU
 
24
    using this patch.
 
25
 
 
26
 6. IF AND ONLY IF the maintainer approves the patch (or doesn't
 
27
    respond within four days), upload the NMU to the incoming
 
28
    directory and send the patch to the BTS.  If the NMU is not
 
29
    approved, go back to 4. or add the NMU to your homepage, but do
 
30
    not upload it to the Debian archive.
 
31
 
 
32
 7. Properly sized and well-written patches sent to the BTS are always
 
33
    appreciated, even if they are rejected later.  They demonstrate a
 
34
    potential solution which could probably improved into a real
 
35
    solution.
 
36
 
 
37
 8. NEVER change the way a package is maintained in an NMU, i.e. don't
 
38
    remove dh_* stuff or switch to dh_* respectively.  This rule
 
39
    applies to all NMU's, not only to an NMU for this package.
 
40
 
 
41
These rules always apply.  They even apply if somebody declares NMUs
 
42
as ok and reduces regular NMU rules to a delay of zero days.  Unless
 
43
I'm on vacation or on a show I am reachable via mail, so there is
 
44
hardly a reason not to contact me.
 
45