This is a tracking bug for the remaining issues in deploying the updated Review Board fork, the new rbbz extension, and the hg review repo & hook.

Added Bug 889431. Docs for prod at https://mana.mozilla.org/wiki/display/websites/reviewboard.mozilla.org I believe the only remaining bits are updating the mysql schema (bug 1013156), nagios monitoring, backups, and actual user testing.

I agree that bug 508541 (putting the associated review with the r+) would be nice, but I can't justify it as a blocker unless there's some crucial reason for it that I don't understand.

(In reply to Mark Côté [:mcote] from comment #2) > I agree that bug 508541 (putting the associated review with the r+) would be > nice, but I can't justify it as a blocker unless there's some crucial reason > for it that I don't understand. That bug means that bugmails are missing the comments when the review is requested. For current workflows, people often ask questions/point out which parts the reviewer should be looking at in the comment. Bug 508541 has resulted in bzexport being reverted back to the legacy bzapi, although it's more painful in that workflow - since (at least for me, but I imagine others) I typically skip the bug after reading the bugmail, and go straight to the splinter review page, which doesn't include the bug comment. I'm not that familiar with reviewboard, but it seems like the entry point is normally to the overview, which does list the description (and so people are less likely to skip over it), in which case this is less painful than the bzexport case. However it's still slightly annoying, since I often use review request comments in bugmails to decide whether the review will be quick or not, and as such whether to take a look immediately, or in a few hours time - so this issue means having to open every reviewboard request just to see those comments.

Ah I see, I misunderstood this bug; I thought it was about the comments being sent separately, not them being eaten. So I imagine this bug would affect any comments sent to the API when a review flag was set to "+" as well. In that case, I think I'll work around this bug by first posting the r? and then posting the comment right after. That will result in two emails (like you actually get from an r+ right now, before my "fix"), but at least all the info should be there. That work for you until we can get bug 508541 fixed?

That should work well enough such that it's no longer an issue for rollout I think. We'll need to make sure the review request is sent first, so it auto-CCs the user to the bug (if they've left that set in prefs - if not, then they'll just have to read it in the bug or reviewboard overview) and then makes the comment second.

Okay, I've addressed this in my patch for bug 1033489, leaving FIXME comments for whenever bug 508541 is fixed.

I'm retargetting deployment for end of September, since smacleod is still out on sick leave and gps is on PTO for a couple weeks. Doesn't make sense to launch with no engineers on hand.

monitoring is all set.

Last blocker fixed! We've already gotten some more people using this; I think we can advertise more widely now.