Re: [Gnash-commit] [SCM] Gnash branch, hwaccel, updated. release_0_8_9_final-1154-ge290f51

[Rob Savoye]

On 09/07/11 10:55, Sandro Santilli wrote:

> I tend to touch the code only to make it better. In this case, switching
> back to "auto" would not help much it unbuildable anyway, until the
> regression is fixed.

  The FB GUI would build if changed back to 'auto'. We never build with
double buffering, so is isn't a regression, it's a task. It'll build
just fine the way the code is now. You are just being overly fixated on
a minor issue, once again blowing this totally out of proportion. I run
Gnash on a touchscreen based framebuffer platform daily... I have every
interest in making it run well in that environment.

> You can call it however you want, but getting next release out w/out 
> a working fb-gnash would be a big regression. The sooner you fix it the
> sooner we can turn it back to auto and avoid missing other future bugs by
> having each build slave (be it a machine or human) build it with full
> support.

  As the person that actually does the releases, having a fully working
fb-gnash (with both AGG and OpenVG) is a goal. That's why I merged it
into master, so all the remaining issues and tasks can be worked on
before then. Having code in a long-lived branch is a huge problem. Now
everything is synced up, making it easier to go forward. That said, I'm
not sure when the next release will go out, I have some performance
improvements I'd like to do first.

  So can we get back to working on Gnash instead of arguing this minor
issue to death for days and days like usual ?

        - rob -