Bug#914153: Update to version 2.3.0-3 breaks Megaglest

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

Manuel A. Fernandez Montecelo-2
Hi,

Em qua, 21 de nov de 2018 às 15:15, Frank Heckenbach
<[hidden email]> escreveu:
>
> > I think that we should revert this change for the time being, though,
> > because if it was working in this way for about a decade and the
> > programs using FTGL worked "fine" despite having some bug there,
>
> Sorry, they did *NOT* all work fine, see my bug report.

I agree with that, that's why I said "fine" with quotes included.  I
thought about adding "(for some value of 'fine')", but stopped short
:-)

However, from how I understand it, having completely blank rectangles
in the position of letters (which happens with critterding and
darkradiant for example) is worse than what happened before in your
original report -- it would perhaps be the worst case scenario of what
could happen before.

So in short, critterding is completely unusable now in Debian
unstable, probably megaglest can be considered unusable too, and
darkradiant is at least affected (there's a window rendering stuff
that contains what I assume are blank rectangles that are supposed to
be letters).

Others like zaz seem unaffected.


> > there's no need to change this now and break applications with only a
> > few weeks to fix this in 15+ other packages before the freeze.
>
> For me, there was very much a need to change. This was one of the
> reasons I started working on ftgl at all if you remember. Without
> either fix (sammy's or mine), ftgl is useless to me, so I'm not
> gonna do this in my repo.

Yes, I was talking exclusively in Debian, carrying some extra patch or so.


> So what can we actually do now?
>
> - If you view it as an ABI breaking change, I can bump the version
>   to 3.0.0, just let me know. (This would mean that programs using
>   the library would need to be rechecked anyway, right? So if we
>   document this prominently, they'll know what to look for, both in
>   source code and in program behaviour.)

Theoretically an ABI change gets solved with a simple recompilation,
and from what I understand it this is more like an API change (it
doesn't break when compiling but the results are not good so as to
make some programs unusable).  So more than an ABI change this is
worse because it needs fixes in the code.

Since in Debian we cannot fix this in one sweep, and we need other
maintainers to help to bring their packages to compliance, this is
tricky.

The worst case is if there are popular applications that are installed
by 3rd parties and that we don't even have in Debian, in which case we
break those too.  Not sure if this is the case, but it can
theoretically happen.


> - If you insist on a version without either of those bugfixes, do
>   this in your code, but then I'm out, sorry. For me this will mean
>   at least 2 more years working with an out-of-distro version (and I
>   fear it would get neglected again, so maybe more like 10 more
>   years or forever), so I'd have no reason to care about the distro
>   version.

Let's try to avoid that, it's not good neither for FTGL nor Debian nor
the people involved :)


> - Otherwise just let the other packages find and fix the resulting
>   bugs, like the saying goes "better ask for forgiveness than for
>   permission".

The problem with this solution is that those packages that are broken
and which maybe cannot be fixed, will be unusable in Debian for a full
cycle.

Is there a way to easily determine when the applications are buggy by
searching the code?  Maybe we can find an upper limit to the
problematic applications, or provide patches, if feasible.


> - A slightly more complex solution would be a flag to select the
>   behaviour. Of course, it would need to be a runtime flag. It may
>   default to the old behaviour, but that should be deprecated (and
>   print a strong depreciation message -- unfortunately that would
>   have to be at runtime too AFAICS, or is there a way to warn at
>   compile time when a program, say, does *not* reference a
>   particular function?).

I am not familiar with OpenGL stuff.  Is there a way to detect if a
"Blending Mode" is provided at runtime, when the function is called,
and if not, provide a default one like the one before, and possibly
emitting errors for it to raise attention (both compile time and
runtime)?

Another option would be to have an extra argument in the function, say:

  inline FTPoint FTBitmapFontImpl::RenderI(const T* string,
                                           const int len,
                                           FTPoint position,
                                           FTPoint spacing,
                                           int renderMode,
                                           bool disableBlend = false);

Or perhaps a new function to enable/disable globally if the library is
initialised, or an env flag, or similar.

And I think that the default would have to be the old behaviour, yes,
because after many years behaving in that way the applications must
have learned to adapt or cope, and no one knows that they have to use
a different flag or invoke the method with an extra parameter.

I realise that maybe this is not what you like because applications
will ever remain buggy, but reallistically, some might even be
abandoned upstream, so they could remain unusable forever.


Cheers.
--
Manuel A. Fernandez Montecelo <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

Frank Heckenbach-4
Hi,

> Em qua, 21 de nov de 2018 às 15:15, Frank Heckenbach
> <[hidden email]> escreveu:
> >
> > > I think that we should revert this change for the time being, though,
> > > because if it was working in this way for about a decade and the
> > > programs using FTGL worked "fine" despite having some bug there,
> >
> > Sorry, they did *NOT* all work fine, see my bug report.
>
> I agree with that, that's why I said "fine" with quotes included.  I
> thought about adding "(for some value of 'fine')", but stopped short
> :-)
>
> However, from how I understand it, having completely blank rectangles
> in the position of letters (which happens with critterding and
> darkradiant for example) is worse than what happened before in your
> original report -- it would perhaps be the worst case scenario of what
> could happen before.

For some value of "worse". For me, it could as well draw unicorn
rainbows; shipping my software with wrong colour effects is simply
inacceptable.

> Is there a way to easily determine when the applications are buggy by
> searching the code?  Maybe we can find an upper limit to the
> problematic applications, or provide patches, if feasible.

The upper limit is of course, all applications that use FTGL and
render letter (which is probably the same as all applications that
use FTGL at all). As things can be resolved differently in the
caller (which is basically the purpose of the change), I don't think
there's an easy way to check it automatically.

> > - A slightly more complex solution would be a flag to select the
> >   behaviour. Of course, it would need to be a runtime flag. It may
> >   default to the old behaviour, but that should be deprecated (and
> >   print a strong depreciation message -- unfortunately that would
> >   have to be at runtime too AFAICS, or is there a way to warn at
> >   compile time when a program, say, does *not* reference a
> >   particular function?).
>
> I am not familiar with OpenGL stuff.  Is there a way to detect if a
> "Blending Mode" is provided at runtime, when the function is called,
> and if not, provide a default one like the one before, and possibly
> emitting errors for it to raise attention (both compile time and
> runtime)?

All I know is that OpenGL state is a complex beast, and even if
there's a way to query relevant info, it wouldn't be recommended as
it adds a round-trip and thus latency. OpenGL is supposed to be used
unidirectionally as much as possible. And it would smell like a
kludge anyway.

> Another option would be to have an extra argument in the function, say:
>
>   inline FTPoint FTBitmapFontImpl::RenderI(const T* string,
>                                            const int len,
>                                            FTPoint position,
>                                            FTPoint spacing,
>                                            int renderMode,
>                                            bool disableBlend = false);

Apart from the (slight) runtime overhead, this seems to make it hard
to change the default to the new behaviour later.

> Or perhaps a new function to enable/disable globally if the library is
> initialised, or an env flag, or similar.

That's more like what I had in mind. But if the default is the old
behaviour if this function is not called, and we want to deprecate
this, we can only warn at runtime (unless, as I said, there's a way
to find out at compile time that the function is not referenced --
sure, one could reference the function without calling it, but that
would be malicious, not worth worrying about).

> And I think that the default would have to be the old behaviour, yes,
> because after many years behaving in that way the applications must
> have learned to adapt or cope, and no one knows that they have to use
> a different flag or invoke the method with an extra parameter.

For some value of "the applications". You're talking about Debian
only again, of course, but there are other applications that have
come to expect the new behaviour (obviously at least mine and the
patch author's ones, possibly more -- there's a number of forks of
FTGL on github, probably by people who use(d) it).

> I realise that maybe this is not what you like because applications
> will ever remain buggy, but reallistically,

The same applies vice-versa for applications that rely on the new
behaviour if we make the old one the default.

The problem is we have different semantics already (and for almost
10 years apparently).

Perhaps the only sane way out is to add *two* new versions of each
rendering function, one with each behaviour, and deprecate the old
ones entirely. This will require changes in all applications (if
only to select the correct one of the two which should be easy if
ones knows which branch of the library they used before), but at
least it will be clear at compile time.

> some might even be
> abandoned upstream, so they could remain unusable forever.

If they're abandoned, what's their expected lifetime anyway?
I've seen enough packages disappear from Debian, so much that I
actually refrain from reporting bugs to fragile applications (in the
sense of dubious maintenance) for fear that the resolution will be
to simply drop them.

Cheers,
Frank

Reply | Threaded
Open this post in threaded view
|

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

Frank Heckenbach-4
In reply to this post by Manuel A. Fernandez Montecelo-2
Hi,

coming back to my own mail, after thinking about it some more:

: > And I think that the default would have to be the old behaviour, yes,
: > because after many years behaving in that way the applications must
: > have learned to adapt or cope, and no one knows that they have to use
: > a different flag or invoke the method with an extra parameter.
:
: For some value of "the applications". You're talking about Debian
: only again, of course, but there are other applications that have
: come to expect the new behaviour (obviously at least mine and the
: patch author's ones, possibly more -- there's a number of forks of
: FTGL on github, probably by people who use(d) it).
:
: > I realise that maybe this is not what you like because applications
: > will ever remain buggy, but reallistically,
:
: The same applies vice-versa for applications that rely on the new
: behaviour if we make the old one the default.
:
: The problem is we have different semantics already (and for almost
: 10 years apparently).
:
: Perhaps the only sane way out is to add *two* new versions of each
: rendering function, one with each behaviour, and deprecate the old
: ones entirely. This will require changes in all applications (if
: only to select the correct one of the two which should be easy if
: ones knows which branch of the library they used before), but at
: least it will be clear at compile time.

That seems to me the best solution indeed. So I can offer this:

- I add these two new versions for all functions involved (quite a
  few); we'd just need to agree about naming ("old" and "new" won't
  do, since in this complicated situation it's not even clear which
  one is old and which one is new; different users will view it
  differently, just like in special relativity ;), also "old" and
  "new" in function names always sounds silly; so perhaps something
  like "RenderBasic" and "RenderDefault" or so ...).

- I deprecate the "Render" functions, adding a special README to
  explain things.

- I change my sources to use "RenderBasic" (or whatever it'll be
  called) and test them. Other users of this fork will have to do
  the same (hopefully after seeing the deprecation warnings and
  reading that README).

- I release 2.4.0 with those changes.

- You put 2.4.0 in Debian. Applications using it will get the
  deprecation warnings, but should otherwise work.

- A bit later, I remove the deprecated functions and release 3.0.0.

- After the release of Buster, you put 3.0.0 in Debian with the
  required transitions.

- Applications using it will break, but fixing them will only
  require changing "Render" to "RenderDefault" in some places
  (which are found by compiler errors). This can also be done before
  you upload 3.0.0 (as "RenderDefault" will be available in 2.4.0
  already), so the transition can be smoohter.

Does this sound like a viable plan?

Cheers,
Frank

Reply | Threaded
Open this post in threaded view
|

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

Frank Heckenbach-4
According to https://release.debian.org/buster/freeze_policy.html:

2019-01-12 - Transition freeze

Is there still time yet to get a fix in, or is it FUBAR already?

Frank

Reply | Threaded
Open this post in threaded view
|

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

Manuel A. Fernandez Montecelo-2
Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
<[hidden email]> escreveu:
>
> According to https://release.debian.org/buster/freeze_policy.html:
>
> 2019-01-12 - Transition freeze
>
> Is there still time yet to get a fix in, or is it FUBAR already?

Transition freeze means ABI changes in libraries are forbidden.  We're
almost in soft-freeze now, more info at:
https://lists.debian.org/debian-devel-announce/2019/01/msg00008.html

Sorry, I've been very busy since end of November, with unexpected work
and family loads.

I have to review the situation again, I completely swapped it out of
my memory.  Assuming that the changes in a new release do not change
other behaviour, or that I can cherry pick a targeted fix for this
problem, we're still good to go.

Cheers,
--
Manuel A. Fernandez Montecelo <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

Frank Heckenbach-4
> Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
> <[hidden email]> escreveu:
> >
> > According to https://release.debian.org/buster/freeze_policy.html:
> >
> > 2019-01-12 - Transition freeze
> >
> > Is there still time yet to get a fix in, or is it FUBAR already?
>
> Transition freeze means ABI changes in libraries are forbidden.  We're
> almost in soft-freeze now, more info at:
> https://lists.debian.org/debian-devel-announce/2019/01/msg00008.html

So do we have time until the soft freeze on 2019-02-12 (I hope not)
or the full freeze (2019-03-12) to get a 2.4.0 uploaded?

> I have to review the situation again, I completely swapped it out of
> my memory.

My suggestion of 2018-11-25 still stands. But if you want me to do
my part of it, please do your review quickly and tell me soon
(or, if it's indeed necessary for the soft freeze, immediately) to
avoid running out of time.

> Assuming that the changes in a new release do not change
> other behaviour, or that I can cherry pick a targeted fix for this
> problem, we're still good to go.

Not much to cherry pick AFAICS. This issue is the only discrepancy
between our versions and if we find a (transitory) solution, we'll
be in sync.

Cheers,
Frank