This page contains information about the "DDPO by mail" initiative. It was announced in this debian-devel@ thread.
Frequently asked questions
That bug is closed, why don't you (and the BTS) agree?
The BTS now uses Version Tracking. See the version graphs in the top right corner, and BugsVersionTracking for details.
That bug doesn't affect stable, why do you say I should fix it there?
If you don't know about the BTS' version tracking system, take a look at the above question first.
Secondly, sometimes happens that the version of a package is the same in stable as in unstable when the bug is reported, but the issue is only relevant to sid; in this case, you should set the 'sid' tag, so that the Bugs Tracking System knows it.
What if the bug only affects <stable release>? then set the tag of the name of the release; i.e. 'lenny' for lenny, and so on
Why am I receiving that mail?
You are receiving that mail if you are maintainer or uploader of at least one package that qualifies. To quality, a package must:
- have an RC bug older than X days
- or have not been in testing for more than Y days
- or have been unable to migrate to testing for more than Z days
With X, Y, Z being determined before each run, to send a sensible number of mails.
If you are the uploader of a package, and one of the co-maintainers of that package is a mailing list (email matches @list.*\.debian\.org), that package is ignored. The rationale is that, if there's a mailing list, you are probably subscribed to it, and there's no need to inform you twice if we can avoid it.
Why are these mails being sent unsolicited with a manual "opt-out" procedure, instead of allowing folks to '''opt-in''', as is best-practice for email services? (added by IvanKohler)
- Those mails were discussed on debian-devel@, and a very large majority of developers were in favor of it
- So far, it provided good results, with many developers "discovering" problems
- Making this opt-in totally defeats the purpose
- It's easy to unsubscribe
"was not able to migrate to testing". What does this mean?
The script measures the number of days since the last time the versions of the package in unstable and in testing were the same. So this actually means that your package has been trying to migrate to testing, but failed to migrate, for more than 100 days.
My package failed to build on one arch. What should I do?
It is the maintainer's responsibility to ensure that his/her package is built on all supported architectures.
When facing a failure, try to determine if it's an architecture-specific failure, or a buildd/chroot-specific failure.
For buildd problems, contact the buildd admins: ARCH@buildd.debian.org
For architecture-specific problems, contact the porters: debian-ARCH@lists.debian.org (be careful: some arches don't have lists, e.g armel -> arm)
In doubt, contact both.
Note that porters can't request a rebuild of your package. Only buildd admins can.
See section 5.10 of the developers reference: http://www.debian.org/doc/developers-reference/pkgs.html#porting
My package doesn't migrate because of some dependencies. Why aren't those problems ignored? I can't do anything about it anyway!
In some cases, it's true that, when there's a single package blocking a lot of other packages, it would be a good idea to be able to not report the issue on all the blocked packages.
However, it's not done currently, because:
- the script currently doesn't understand britney's output, which would be required to analyze on which other package a package is waiting.
- in many cases, notifying the maintainer of the problem is still a good idea, because the maintainer of the blocking package might be inactive. In that case, the "blocked" maintainer could ping the "blocking" maintainer.
- it's only a monthly email, it's not _that_ noisy.
If someone want to write the code, I'd happily include it. The idea would be to generate a list of packages on which each package is waiting. This way, we could say that, if one of the "blocking" packages is xulrunner or boost, we don't need to report the problem.