On Sunday, 2017-11-26 17:24:09 -0800, Eric Anholt wrote: > Eric Engestrom <eric.engest...@imgtec.com> writes: > > > On Wednesday, 2017-11-22 12:28:17 -0800, Eric Anholt wrote: > >> Jordan Justen <jordan.l.jus...@intel.com> 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? 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 mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev