[Mesa-dev] [PATCH mesa 0/7] remove upstreamed specs

[Ian Romanick]

On 11/27/2017 02:24 AM, Eric Engestrom wrote:
> On Sunday, 2017-11-26 17:24:09 -0800, Eric Anholt wrote:
>> Eric Engestrom <eric.engestrom at imgtec.com> writes:
>>
>>> On Wednesday, 2017-11-22 12:28:17 -0800, Eric Anholt wrote:
>>>> Jordan Justen <jordan.l.justen at 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?

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
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>