Using preferredemail as a public email id is wrong and broken.

The problem seems to be that DirectBranchCommit produces a bzr user id from format_address_for_person(branch.owner), but format_address_for_person won't work if the person in question has no preferred email.

In the case of Datum, and probably a lot of the other failing branches, the owner is a team and has no contact address. We'll have to search much harder for a valid email address.

The failure is the result of the fix for bug 614404 (that fix being required for a bzr upgrade).

Discussed this with Robert. The hard part is that there are apparently a lot of other places that make this same broken assumption. We'll want a single "get an email address for this person, even if it's not the right one" function for use in all these places.

Most or all of the changes that need this extra guard will be in http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/11369

Discussed with Aaron. He says there is no real fix for this; we must have a public email address (real or fake, but selected by the user) that we can pass to bzr as the committer id. That means that we have to let these exports continue to fail, but email the branch owners that they need to set a preferred email address (in the case of users) or contact addresses (in the case of teams).

Most of the problem is likely to be for teams without contact addresses. These will generally be easy to reach regardless.

Team and user addresses are handled separately, but as far as I can tell code that uses Person.preferredemail (as this code does) should pick up a team's contact address as well.

As I said in my question #125775, the problem appeared after the 2010-09-08.
I confirm that setting an e-mail address yesterday allow an exportation today.
Thanks

Thanks for the confirmation, Olivier! It looks like we may have to ask this of all teams. The complications reach much further than the Translations app, and we're not sure we'll be able to resolve them completely.

Discussed with Tim. We can set a more appropriate committer string in the translations-to-branch export script (and extend DirectBranchCommit) to permit this.

A fix is on approach for landing on devel (see attached branch). It will still have to go through Q/A before it can be deployed in production, but after that the exports should resume, without any need to set an email address.

This is probably not the perfect perennial fix for the wider problem. But it will get the exports going again and at the same time make it clearer where these commits come from.

Fix is in db-devel 9818.

Fixed in stable r11599 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11599>.

I'm currently trying to get the fix cowboyed onto the staging server so I can test it in a realistic setting prior to production deployment.

The fix has passed quality control on the staging server. I will now request a rollout.

We got approval to cherry-pick. The branch is now landing on production-devel; it can be deployed as soon as it promotes from production-devel to production-stable.

The fix is in production-devel revision 9775. We currently have 9774 deployed. The system operators are putting a broken buildbot back together so that 9775 can make it into production-stable.

The branch finally made it into production-stable. I requested the cherrypick that will fix the problem.

The cherrypick is in progress. Tomorrow's exports should all work.

(For most users, the exports worked all along. Only branches owned by teams without contact addresses were affected.)

Cherrypick is complete. As of 2010-09-29, translations-to-branch exports should work again for teams without email addresses.