> > It's time for another try to resolve the gl.h/glext.h issue.
>
> Why? The last vote came down in favor of A. Do we have to keep
> voting until C wins?
FWIW, the last vote was essentially unchanged from the original, depending
on what day you tallied the votes. Blythe was out of town but when he
returned he reasserted his support for C, which gave the nod to C by one
point. But, Thomas was the only person to switch from A to B, and I don't
want him to feel like he was suckered into making a non-strategic vote.
Therefore, even though one could argue C was the winner, I consider that
vote to have been a failure, as nothing really changed from the original
tie.
In light of new information, some people have changed positions now, and
that suggests a re-vote could actually break the deadlock.
> This allows people on either side of the A/C divide to agree
> to a compromise arrangement without having to risk tactical
> voting leading to (as in my case) a move from A to B letting
> in C - which I absolutely cannot tolerate.
In the end its important to remember that some of us may have to live with a
result we find intolerable. I find option A to be intolerable and option B
to be very undesireable. I also found context-independent GetProcAddress to
be intolerable, but I have to live with it now, so I will - enough people
were convinced that it was the right way to go for the long term that the
short term pain it causes some driver people was not a consideration. I see
the legacy concerns you have expressed in a similar light, but less painful
still - I wish I had only to change a makefile to fix my compatibility
issues.
-- Michael
