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

[Eric Engestrom]

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?

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?