No unpopulated rows have appeared in the past 5 days at least. They may still appear, but keeping the populators alive until we've landed the NOT NULL constraints would just serve to hide the bad rows until it was too late. The most likely failure mode would be critical failures after rolling out the constraint.
Alternatively, moving them to --experimental does nothing except save some time looking them up from history. Better, I think, to let any new unpopulated rows accumulate, and repeat the simple SQL check for unpopulated rows before landing the constraints. The most likely failure mode is that we discover bugs before they affect production, with a tiny secondary risk of the first broken row appearing just between the check and rollout. What happens if the check finds bad rows? If we're talking about small numbers, we roll out code fixes and then patch up the database using direct SQL. If they're large numbers, possible but not likely at this point, we'll have to take the risk that while we're writing up that new branch anyway, we'll need to look up the populator code in bzr history or in this MP. I don't think the magnitude of the risk and the minute of extra work in the failure case justify necessitating an extra cleanup branch in the success case. -- https://code.launchpad.net/~jtv/launchpad/bug-849683/+merge/83546 Your team Launchpad code reviewers is requested to review the proposed merge of lp:~jtv/launchpad/bug-849683 into lp:launchpad. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-reviewers Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-reviewers More help : https://help.launchpad.net/ListHelp
