Glucose status/instructions request, (and notes on stale branches)
keithp at keithp.com
Thu Oct 18 20:28:45 PDT 2007
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
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
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.
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg