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

[Jesse Barnes]

On Thursday, October 18, 2007, Alan Hourihane wrote:
> > Anyone is welcome to pull from the glucose branch if they like;
> > pulling from 'not master' will give them a good idea of what to
> > expect in terms of stability.
>
> What I'm also concerned about is what else you veto in favour of your
> terms. Where does that kind of argument end ?

I think there are a few technical reasons that would argue against 
adding another accel architecture to the driver.  One of the main 
problems we have now is that neither of the existing architectures work 
correctly in all situations, and having to maintain both adds to our 
workload a bit.  So if it were up to me, I'd like to see just one, 
solid accel API, in the Intel driver at least, at a time.

Fortunately, the driver side of glucose seems fairly simple, so we 
should have lots of code to delete if it hits master, and I think 
you're right to wait until you have the major issues addressed before 
trying to push it.  On the other hand, a branch containing just the 
glucose stuff should be easy to keep up to date until the server and 
other pieces are ready, so it seems like it wouldn't be much trouble to 
keep it out of master for now (again I'm just thinking of the driver 
tree).  The alternative would be for the next Intel driver release 
manager (which looks to be me after Kyle does his point release) to 
create a separate branch with just the features we'd like to see 
supported in the next release, but it would be nice if we could avoid 
that.  After all, branches are for experimental features and master 
should be for stuff that's done.  As it stands we have too many bugs 
and partially supported features in master...

Any other ideas?  I'm just afraid of going any further down the slippery 
slope of adding "just one more config option" to the driver before it's 
ready or w/o removing others at the same time to keep things simple.

Jesse