Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Hardening the review requirements for changing .webidl files
33 views
Skip to first unread message
Ehsan Akhgari
Apr 24, 2014, 5:14:09 PM4/24/14
to dev-pl...@lists.mozilla.org, dev-b2g, Johnny Stenback
Hi everyone,
As many of you are already aware, we have been working hard towards making
it possible to express our Web facing Javascript APIs in WebIDL. These
.webidl files can be found under dom/webidl in mozilla-central. Over the
past few years we have been trying to be more aware and cautious when
changing any Web facing APIs (which includes additions/removals/changes to
these APIs). While WebIDL doesn't capture every API that we expose to the
Web, a good portion of those APIs are being expressed in WebIDL.
In order to formalize the process of making Web facing changes to Gecko,
we're starting with hardening the review requirements for changing .webidl
files. Starting now, any patch which touches .webidl files should receive
a superreview from an owner/peer of the DOM module (who are listed here: <
https://wiki.mozilla.org/Modules/Core#Document_Object_Model>) that reflects
whether the change made to the file is OK from an API exposure standpoint.
This is in addition to the existing review rules. I have filed bug 1001106
in order to add a push hook which enforces this rule by preventing
changesets without the appropriate superreview to be pushed which should
help remind people if they forget. As part of the superreview process, the
DOM owner/peer may request you to send an intent to implement/ship email to
dev-platform, or otherwise clarify how the patch adheres to our API
exposure guidelines <https://wiki.mozilla.org/WebAPI/ExposureGuidelines>.
I hope that this change is going to help us be better citizens of the Web
platform. Please let me know if you have any questions or concerns.
Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
As many of you are already aware, we have been working hard towards making
it possible to express our Web facing Javascript APIs in WebIDL. These
.webidl files can be found under dom/webidl in mozilla-central. Over the
past few years we have been trying to be more aware and cautious when
changing any Web facing APIs (which includes additions/removals/changes to
these APIs). While WebIDL doesn't capture every API that we expose to the
Web, a good portion of those APIs are being expressed in WebIDL.
In order to formalize the process of making Web facing changes to Gecko,
we're starting with hardening the review requirements for changing .webidl
files. Starting now, any patch which touches .webidl files should receive
a superreview from an owner/peer of the DOM module (who are listed here: <
https://wiki.mozilla.org/Modules/Core#Document_Object_Model>) that reflects
whether the change made to the file is OK from an API exposure standpoint.
This is in addition to the existing review rules. I have filed bug 1001106
in order to add a push hook which enforces this rule by preventing
changesets without the appropriate superreview to be pushed which should
help remind people if they forget. As part of the superreview process, the
DOM owner/peer may request you to send an intent to implement/ship email to
dev-platform, or otherwise clarify how the patch adheres to our API
exposure guidelines <https://wiki.mozilla.org/WebAPI/ExposureGuidelines>.
I hope that this change is going to help us be better citizens of the Web
platform. Please let me know if you have any questions or concerns.
Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
Ehsan Akhgari
Apr 24, 2014, 6:22:35 PM4/24/14
to dev-pl...@lists.mozilla.org, dev-b2g, Johnny Stenback
Following up on this, people asked us to not abuse the superreview flag for
this purpose, which is a fine suggestion, so instead of that, a regular
review from a DOM peer would be required on these changes, and we'll make
the hg push hook check for the names of the DOM peers in the r= flag in the
commit message.
The rest of this proposal remains intact!
this purpose, which is a fine suggestion, so instead of that, a regular
review from a DOM peer would be required on these changes, and we'll make
the hg push hook check for the names of the DOM peers in the r= flag in the
commit message.
The rest of this proposal remains intact!
0 new messages