[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] RE: extension development process



Hi Frank,

On Tue, Feb 10, 2015 at 1:47 AM, Frank Olivier
<Frank.Olivier@microsoft.com> wrote:
> "Rejected extensions should never be implemented. "
>
> I would advocate for slightly different wording, with the same intent:
>
> - Vendors should avoid implementing rejected extensions.

Since the wording about "proposed" extensions is pretty strong in the
extension registry ("they should not be implemented, even under a
vendor prefix") I think the wording should be even stronger about
rejected extensions.

> - Vendors may implement experimental extensions to obtain technical feedback
> and to submit them to the ratification process.

This second one should already be covered by the existing wording in
the extension registry "Draft extensions may be implemented under a
vendor prefix for experimentation purposes". Let me know if this seems
insufficient.

-Ken


> "An extension enters rejected status because consensus on it could not be
> reached at the proposal stage or technical difficulties arise during
> implementation at the draft stage. A community approved extension can only
> be rejected in extraordinary circumstances. A Khronos ratified extension
> cannot be rejected."
>
> Agree with this wording.
>
>
>
> Thanks
>
> Frank
>
>
>
> From: Dean Jackson [mailto:dino@apple.com]
> Sent: Saturday, February 7, 2015 3:15 AM
> To: Florian Bösch
> Cc: public webgl; Frank Olivier
> Subject: Re: extension development process
>
>
>
>
>
> On 7 Feb 2015, at 5:13 pm, Florian Bösch <pyalot@gmail.com> wrote:
>
>
>
> Frank and Dean, could we get it on the record here that you're in agreement
> of this wording?
>
>
>
> Agreed.
>
>
>
> Dean
>
>
>
>
>
> On Fri, Feb 6, 2015 at 8:47 PM, Florian Bösch <pyalot@gmail.com> wrote:
>
> I have introduced the rejected status to the extension registry, added
> wording explaining when an extension can be rejected and clarified the
> process of extension advancement. Below are the added wordings:
>
> Every extension should advance to Khronos ratified. If an extension cannot
> advance through the extension process it can be rejected.
>
>
>
> Rejected extensions should never be implemented. An extension enters
> rejected status because consensus on it could not be reached at the proposal
> stage or technical difficulties arise during implementation at the draft
> stage. A community approved extension can only be rejected in extraordinary
> circumstances. A Khronos ratified extension cannot be rejected.
>
>
>
> This is of course open for debate, but I find it a good idea. Can we form a
> consensus on this?
>
>
>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------