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:

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)

Some points:

"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.

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:

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:

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.