[unixODBC-dev] what should I fix?

Eric Sharkey sharkey at netrics.com
Mon Mar 7 20:11:51 GMT 2005

> Ok, maybe I am not answering the correct question.
> I was under the impression that the cvs mailing list would let me see 
> any changes that were commited to the tree. Thats enough for me, I can 
> take a look at them and if they look like I would have a opinion then I 
> can just ask and we can discuss

Ok.  Perfect.  That's all I needed to know.

> All I was suggesting about the list of directories I was worried about, 
> was I would prefer discussing changes to those before the changes 
> started. Once the change discussed was agreed, then if it wasn't me 
> making the change, I would check it out after it was commited.

I have no plans at all to make significant changes to the driver
manager or related code, but there may be instances where small changes
are required, like the one line SQLSetConnectAttr patch I sent previously.

For one-line bug fixes, there really isn't a lot of discussion that can be
done in advance of the change.

> I thought your main area of work was going to be on the testing parts of 
> the distrib

It is.  But my driver is using the unixODBC supporting libraries
(ini, lst, log, etc.) and to the extent that I feel my driver needs
functionality not currently in these pieces, such as the logPushMsgf
function I just wrote, I'd like to see these changes get incorporated
back into unixODBC.

My ultimate goal is to support my company's database product and make
life easier for my company's customers.  To the extent that improvements
in unixODBC further that goal, it's in my interest to improve unixODBC.
That may mean improving the Debian packaging, or making gODBCConfig have
a resizable layout so that it doesn't look like crap with a non-default
font, or whatever it takes.  The core components, like the DM, look pretty
good to me, it's the peripheral code I'm more concerned about.


More information about the unixODBC-dev mailing list