On 11/27/2017 02:24 AM, Eric Engestrom wrote: > On Sunday, 2017-11-26 17:24:09 -0800, Eric Anholt wrote: >> Eric Engestrom <[email protected]> writes: >> >>> On Wednesday, 2017-11-22 12:28:17 -0800, Eric Anholt wrote: >>>> Jordan Justen <[email protected]> writes: >>>> >>>>> On 2017-11-22 09:59:34, Eric Engestrom wrote: >>>>>> A recent thread [1] made me check our local specs to see which ones were >>>>>> upstream. This series removes the ones that are identical upstream >>>>>> (modulo "TBD" extension numbers in some cases). >>>>> >>>>> While I don't have too strong of an opinion on it, I think we should >>>>> keep a copy of Mesa specs that are in the upstream registry. >>>>> >>>>> I think it makes sense to send a patch to mesa-dev for new Mesa specs >>>>> or changes to Mesa specs. Having a copy in docs/specs works well for >>>>> that. >>>> >>>> The downside is that that process means that we'll inevitably keep stale >>>> or divergent copies in Mesa, when the canonical location for GL specs is >>>> Khronos. We do have a reasonable process for modifying Khronos's specs >>>> now, which we didn't before. >>> >>> Exactly, our local copies are not the authority, Khronos is. >>> >>> Changes to specs should be sent to Khronos, on the relevant repo, by >>> creating a pull request like I've now done for the specs I mentioned >>> in the cover letter: >>> https://github.com/KhronosGroup/EGL-Registry/pull/36 >>> https://github.com/KhronosGroup/OpenGL-Registry/pull/132 >>> https://github.com/KhronosGroup/OpenGL-Registry/pull/133 >>> https://github.com/KhronosGroup/OpenGL-Registry/pull/134 >>> https://github.com/KhronosGroup/OpenGL-Registry/pull/135 >>> https://github.com/KhronosGroup/OpenGL-Registry/pull/136 >>> https://github.com/KhronosGroup/OpenGL-Registry/pull/137 >>> >>>> >>>> I think we should get all our specs out and into the Khronos. >>> >>> Ack; should I let the specs authors do this themselves, or push them for >>> them? >> >> If you have the time and energy to upstream them, I think that would be >> quite welcome. > > Not right now, probably not before Christmas either. > >> I'm sure a lot of these are basically forgotten and >> people's original motivation for the extensions has faded away. > > That's my worry; what's the point of taking time to upstream them if > they're dead? Who will explain why we need them and argue the case in > Khronos?
If the extension is or was ever shipped, that's justification enough to get it in the registry. If there are extensions that never shipped, then there's probably no point. I haven't looked at the list of extensions yet, so I may be talking out of my hat... > I think what I'll do is send a series to mark the remaining extensions > as deprecated, and CC all the people involved in each extension, and let > that series sit for a while. > > If people come out and say "no, I still want this extension", they can > explain why and I'll pass on the explanations to Khronos if they can't. > If I don't hear anything after a few months, I'll go ahead and push the > deprecation patches. > > Does that sound like a plan? > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
