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

[Sandro Santilli]

On Wed, Sep 07, 2011 at 11:06:04AM -0600, Rob Savoye wrote:
> 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.

Oh, ok. We can separate the two issues then.
I'll leave w/out double buffering for some time.

> 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 ?

Sure. Let's move on.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html