A community approved extension can only be rejected in extraordinary circumstances.Apparently it was widely supported at the time the extension was created, but it looks like now it is no longer available on AMD (according to the OpenGL capabilities database & on my own machine) making it only possible to implement on Qualcomm devices. Since there are other, newer compressed texture formats available on Qualcomm, this extension seems pretty useless.The AMD_compressed_ATC_texture spec is very old and underspecified. This is creating quite a bit of maintenance work for the conformance tests and browsers - the tests fail currently on Qualcomm (the only platform where they're available), despite Qualcomm seeming to conform to the underspecified spec.Are there any objections to rejecting this extension?I'll summarize the circumstances for the reason for rejection thus:
- Only marginally supported by hardware
- Badly specified upstream
- Unreliable when actually usedDo these conditions meet the criteria of "extraordinary circumstances"? If so, how can we avoid promoting extensions to community approved in the future that would befall the same fate?
A brief history of this extension:
- Introduced by Benoit Jacob in 2012 as draft (back then the proposal status didn't exist). A poll for objections on the ML didn't net any response or objection so after 3 days it was put into draft status.
- No discussion of atc happened at all for 2 years, support status remains marginal.
- Proposed to move to community approved by Kenneth Russel in 2014 it got swept up in an effort to promote several draft extensions prior to iOS gaining WebGL support. Jeff Gilbert, Brandon Jones and Dean Jackson replied to the poll in favor to community approve, and one day later Kenneth moved these extensions (including atc) to community approved.
- No discussion of atc happened at all for the next 3 years (which brings us to today)I believe that a pattern is discernible here:
- No rigorous discussion seems to occur on the extension
- Moving from one status to another is quickly enacted after only brief polling periods
- Participants in what little communication there is are not diverse (only seem to include UA vendors)
- Years after its introduction the extension is largely unsupported
- The extension gets lumped together with others instead of getting the attention it should have gotten.From this I believe we can formulate a guideline on how to avoid this situation:
- If an extension isn't announced on the ML or isn't discussed at all, then the quality of any poll for consent is suspect.
- It should only move to a new status after a grace period that should be somewhat longer than a few days (maybe a month or two?)
- It would be preferable if input from multiple constituents is present, and if that is lacking, calls should be made to those constituents to render an opinion.
- If an extension lingers with barely any support, it might indicate trouble and should be investigated.
- An extension status change should not be lumped together with others, for it could obscure issues in the status change.