We've had a policy requiring super-review for certain kinds of patches for a long time. It's changed a couple of times but the current policy (http://www.mozilla.org/hacking/reviewers.html) primarily requires super-review for any patch that introduces or changes an API. Basically any function in a JS file or JSM is covered here, or at least that is my reading of it. The reasoning is pretty straightforward, designing APIs well up front reduces the maintenance burden in the future and hopefully means we don't have to make changes that break add-ons.

The problem is that I frequently come across patches that were landed without super-review despite meeting the requirements. This suggests that many reviewers aren't aware of the policy or don't have the same interpretation of it as I do. We probably need to do a better job of making sure that all reviewers in particular understand the policy and are following it.

But, I haven't yet seen an issue arise from this lack of SR. Does that mean that the policy is too restrictive and we need to change it to more closely match how reviewers are working?

Either we're setting ourselves up for big problems down the road or we have a policy that is in some cases hindering development. Those are the extremes of course and the reality is probably somewhere in between, but I'd like to hear other people's thoughts about this.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to