gdi32: Improve detection of symbol charset for old truetype fonts.

[Sebastian Lackner]

On 18.11.2015 11:31, Dmitry Timoshkov wrote:
> And that's true for any other patch regardless of the area and amount of
> code. Basically any patch can have side effects, but if even in the first
> week of code-freeze any patch is considered as risky, then I don't know
> how you are going to fix the regressions or any bugs during that time.
> 

I do not want to heat up the discussion, but this is indeed a valid concern, and
its also a bit unclear to me what exactly is allowed during the code freeze. In
theory, almost every commit could cause regressions. When adding new stubs
applications might use a different code paths. When fixing one issue, it might
reveal a different one somewhere else.

And especially regarding the remaining regressions: those which already exist
for a long time often aren't that easy to fix and also might require reworking a
lot of the existing code. This means the risk of adding new regressions is quite
high, when they are applied without any testing.

Imho, the only guarantee to ensure a really stable version, would be to develop
on both "stable" and "development" in parallel, and frequently backport patches
which have been tested well enough - basically similar to our Staging tree.
Unfortunately this doesn't force anyone to work on regressions ... ;)

So, what kind of patches are acceptable during the freeze period? If we are too
strict, basically only minor cleanup is possible. I still have various patches I
would like to send (x86_64 marshalling, ...), but a small risk of regressions is
always there.