I recently posted in the newsgroups about a concern over super-review. In some cases patches that seem to meet the policy aren’t getting super-reviewed. Part of the problem here is that the policy is a little ambiguous. It says that any API or pseudo-API requires super-review but depending on how you read that section it could mean any patch that changes the signature of a JS function is classed as an API. We need to be smarter than that. Here is a straw-man proposal for defining what is an API:
Any code that is intended to be used by other parts of the application, add-ons or web content is an API and requires super-review when added or its interface is changed
Some concrete examples to demonstrate what I think this statement covers:
- JS modules and XPCOM components in toolkit are almost all intended to be used by applications or add-ons and so are APIs
- UI code in toolkit (such as extensions.js) aren’t meant to be used elsewhere and so aren’t APIs (though they may contain a few cases such as observer notifications, these should be clearly marked out in the file)
- Any functions or objects exposed to web content are APIs
- The majority of code in browser/ is only meant to be used within browser/ and so isn’t an API. There are some exceptions to this where extensions rely on certain functionality such as tabbrowser.xml
Do you think my simple statement above matches those cases and others that you can think of? Is this a good way to define what needs super-review?