Who owns dblib?

Scott C. Gray gray at voicenet.com
Fri Jun 23 07:52:35 EDT 2000


On Fri, 23 Jun 2000, Geoff Winkless wrote:

> Scott Gray (We're not worthy!!! ;-) writes:

Ahh, shucks. :)

> > Another option, would be to branch the code, and let these changes
> > be considered FreeTDS 2.0 while the 0.XX->1.XX branch continues
> > unchanged.  I prefer this option myself.
> 
> > But, I have a vested interest in getting ct-lib working
> > as well as possible (primarily against MS SQL Server--and, in fact,
> > I can do much of this work on business hours) and I would like to
> > continue to feed my changes back to the rest of the world so that
> > everyone can benefit.
> 
> My 2p's worth:
> 
> I don't think we can ask you not to do the work you want to do - firstly
> because open-source demands that if you want to make changes you can, 

Sure. I wasn't saying that I wouldn't make my changes (I really _need_
to make these changes), just that, if necessary, I would just make
them available separately from the actual FreeTDS archive.   Obviously
I would prefer not to do this if I don't have to--branching in this
way is not really healthy.

> but
> mainly because there aren't too many developers working on the project for
> any large amount of time, and you're probably one of the few people who can
> work on this during real working hours - I know I can only spend day-time on
> the code when it impacts on the systems we use here.

Unfortunately, I can't work on it full time--I am really doing
project management now and am not supposed to be coding, but... :)

(Actually I have been itching to contribute ever since I was working
at Sybase, but obviously that wouldn't work.  I am still shying away
from contributing too much to the reverse engineering of the TDS 5.0
protocol--7.0 is OK--Just In Case. However, from my development work
with OpenSwitch, I gained an _extremely_ intimate knowledge of 
the ins-and-outs of CT-Lib and Open Server API's, so I would like to help
carry that knowledge into FreeTDS.)

> What I would like to see is a release of the current CVS codebase, now that
> it's stable enough to be used (in the main), with only bugfixes allowed (a
> "feature freeze" if you will) and then you start rewriting your version, and
> any new changes go to that. I really can't see any point in continuing to
> flog a dead horse by splitting the development.

I agree. I would like to see

  o  Continue the current code line as FreeTDS < 2.0. I think that
     feature additions are ok, though. I am already rolling fixes
     that are being applied to the 0.50 release into my changes.
  o  I will finish my TDS layer changes (back-porting major bug fixes
     if necessary) and documenting the public interface.
  o  I will also work on updating the ct-lib layer to use the new
     changes.
  o  Hopefully, others can take the initiatives to move the dblib
     and odbc layers forward (if I had infinite time, I would do it
     myself).

-scott

--
Scott C. Gray <gray at voicenet.com>     "my keybard is brken"
       http://www.voicenet.com/~gray/sqsh.html




More information about the FreeTDS mailing list