Glucose status/instructions request, (and notes on stale branches)

[Alan Hourihane]

On Thu, 2007-10-18 at 20:28 -0700, Keith Packard wrote:
> On Thu, 2007-10-18 at 21:00 +0100, Alan Hourihane wrote:
> 
> > Suppressing this code is not the answer, and the last statement shows
> > it's just your opinion, which shouldn't be the overriding factor here.
> 
> Yes, it's partially a selfish desire to reduce my workload, but at this
> point, I see a bunch of cleanup work that needs doing before we're
> really ready to support glucose in a production release of the driver.
> Having that done before it hits master means that people using master
> will see fewer regressions and fewer significant changes shortly
> afterwards.

glucose in the driver is very simple Keith, there's really no burden in
the driver. It's all outside of it in the supporting code.

> I've spoken often about the desire to reduce our driver complexity by
> looking to GL as a shared rendering API, so I'm on the record as
> supporting the general plan here, I'd just like to moderate the flux in
> master to keep things more stable. With Mesa moving to Gallium, it may
> be reasonable for X to look to Gallium as well, instead of using OpenGL.
> I don't know, but you're asking us to switch from a single layer (EXA)
> to four (glucose, glitz, mesa, dri). With several of those layers in
> flux, it seems prudent to avoid standardizing any of them before they're
> ready.

I'm not asking you to switch to anything. Crikey, XAA has remained the
default even with all the flux of EXA. 

I've said glucose is another choice. Isn't freedom of choice where we
are at these days ?? You are just removing that choice by not allowing
the code to master.

> Jesse and I are planning on starting quarterly releases of the intel
> driver, but that is going to require some more care in merging bits to
> master as we'll have only a few weeks or so at each release to stabilize
> and prepare the release. To make this work, we're going to need more
> communication about when new user-visible functionality is merged into
> the driver. I'm hoping we'll be able to get the first quarterly release
> done in mid November, but we haven't really figured out the precise plan
> at this point.

Alan.