This page contains information about the "DDPO by mail" initiative. It was announced in this [http://lists.debian.org/debian-devel/2007/06/msg01063.html 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 [http://wiki.debian.org/BugsVersionTracking] for details.

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: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-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:

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.