On Fri, Jun 21, 2013 at 1:45 PM, Andrew Overholt <overh...@mozilla.com>wrote:
> Back in November, Henri Sivonen started a thread here entitled "Proposal: > Not shipping prefixed APIs on the release channel" [1]. The policy of not > shipping moz-prefixed APIs in releases was accepted AFAICT. > > I've incorporated that policy into a broader one regarding web API > exposure. I'd like to see us document this so everyone can easily find our > stance in this area, similar to how they can with Blink [2]. > > I've put a draft here: > > > https://wiki.mozilla.org/User:**Overholt/APIExposurePolicy<https://wiki.mozilla.org/User:Overholt/APIExposurePolicy> > > I'd appreciate your review feedback. Thanks. > > [1] > https://groups.google.com/d/**msg/mozilla.dev.platform/** > 34JfwyEh5e4/emA1LAoVEVQJ<https://groups.google.com/d/msg/mozilla.dev.platform/34JfwyEh5e4/emA1LAoVEVQJ> > > [2] > http://www.chromium.org/blink#**new-features<http://www.chromium.org/blink#new-features> > ______________________________**_________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/**listinfo/dev-platform<https://lists.mozilla.org/listinfo/dev-platform> > Thanks for putting this together Andrew. It's an excellent starting point. My concerns are: 1. "at least one other browser vendor ships -- or publicly states their intention to ship -- a compatible implementation of this API" Because Apple and Microsoft generally do not publicly comment on upcoming features, and Presto is no more, in practice this will boil down to a minimum condition of the Blink developers stating their intention to ship an API (in Chrome, presumably). That feels too restrictive to me. Blink's policy talks about "positive signals" from other vendors which is much more vague. I worry that the proposed language is too rigid and will either restrict us from innovating or worse, be ignored. 2. "during the first 12 months of development of new user-facing products, APIs that have not yet been embraced by other vendors or thoroughly discussed by standards bodies may be shipped *only as a part of this product *" I assume this is some sort of backdoor for B2G or something? When do we start counting 12 months? From beginning development or from shipping? What happens when it's over? Do we have to disable all the APIs we shipped under this clause? If the product actually succeeds that's never going to happen ;-) 3. " It must also demonstrate that an API is standardized as defined below." The link on "defined below" doesn't actually go anywhere, and it's not clear to me where it should go. 4. "Disputes between the API review team and the API developers will be decided by the module owner for the API's area." I'm not sure that there is even a module owner here to decide things. Large new APIs (e.g. IndexedDB, workers) have become their own modules, and some are defacto modules (e.g. Bluetooth). If the module owner and the API developer are the same person there's clearly a conflict of interest here ;-) 5. "Once one week has passed, if there have been no dissenting voices and all of the above steps have been followed, the code may be checked in to mozilla-central." This seems unnecessarily heavy-handed to me. Everything big landing on m-c is supposed to be either pref-controlled or easy to backout anyways as part of the train model, so I think we can just land and if someone raises a problem during the "intent to ship" phase we can deal with it. 6. "We are considering implementing a commit hook ensuring all new WebIDL files have the required sr+. No decision has been made at this time." Just so we're all aware, this would only cover a portion of the problem space. There are lots of ways to make web visible API changes without fiddling with any WebIDL files. 7. "should we have a joint mailing list with Blink for intent to implement/ship?" Not sure how the Blink folks feel about this but I think this would be an excellent idea. - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
