+ <sect id="inform-vacation">Going On Vacation Gracefully
+ <p>
+Most of the developers take vacation, usually this means that they can't
+work for Debian and they can't be reached by email if any problem occurs.
+The other developers need to know that you're on vacation so that they'll
+do whatever is needed when such a problem occurs. Usually this means that
+other developers are allowed to NMU your package if a big problem (release
+critical bugs, security update, ...) occurs while you're on vacation.
+ <p>
+In order to inform the other developers, there's two things that you should do.
+First send a mail to &email-debian-private; giving the period of time when
+you will be on vacation, you can also give some special instructions on what to
+do if any problem occurs. Next you should update your information
+available in the Debian LDAP database and mark yourself as « on vacation »
+(this information is only accessible to debian developers). Don't forget
+to remove the « on vacation » flag when you come back.
+
+ <sect id="upstream-coordination">Coordination With Upstream Developers
+ <p>
+A big part of your job as Debian maintainer will be to stay in contact
+with the upstream developers since you'll have to share information that
+you get from the Bug Tracking System. It's not your job to fix non-Debian
+specific bugs so you have to forward the bugs to the upstream developers
+(of course, if you are able to fix them, you can ...). This way the bug
+may be corrected when the next upstream version comes out. From time to
+time, you may get a patch attached to a bug report, you have to send the
+patch upstream and make sure that it gets included (if the authors accept
+the proposed fix). If you need to modify the upstream sources in order to
+build a policy conformant package, then you should propose a nice fix
+to the upstream developers which can be included so that you won't have to
+modify the sources of the next upstream version. Whatever changes you
+need, always try not to fork from the upstream sources.
+
+ <sect id="rc-bugs">Managing Release Critical Bugs
+ <p>
+Release Critical Bugs (RCB) are the bugs of severity « critical »,
+« grave » and « important ». Those bugs can delay
+the Debian release and/or can justify the removal of a package at freeze
+time. That's why those bugs needs to be corrected as fast as possible.
+You must be aware that some developers who are part of the <url
+id="&url-debian-qa;" name="Debian Quality Assurance"> effort are following
+those bugs and try to help you each time they can. But if you can't
+fix such bugs within 2 weeks, you should either ask for help by sending a
+mail to the Quality Assurance (QA) group (&email-debian-qa;) or
+justify yourself and gives your plan to fix it by sending a mail to the
+concerned bug report. Otherwise people from the QA group may want to do a
+Non Maintainer Upload (NMU) after trying to contact you (they might wait
+not as long as usually before they do their NMU if they have seen no
+recent activity from you on the BTS).
+
+ <sect id="qa-effort">Quality Assurance Effort
+ <p>
+Even if there is a dedicated group of people for Quality Assurance, QA is
+not reserved to them. You can participate to this effort by keeping your
+packages as bug free as possible, as lintian-clean (see <ref
+id="lintian-reports">) as possible. If you think that it's quite impossible,
+then you should consider orphaning (see <ref id="orphaning">) some of your
+packages so that you can do a good job with the other packages that you
+maintain. Alternatively you may ask the help of other people in order to
+catch up the backlog of bugs that you have (you can ask for help on
+&email-debian-qa; or &email-debian-devel;).
~ianmdlvl / developers-reference.git / commitdiff