FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Hi Steve, 

> After a bit of delay, I'm looking at packaging up the freetds 0.91
> release for inclusion in Debian and Ubuntu.  However, since I'm now
> entirely using a distributed VCS workflow for all my packages (bzr),
> I'm running into a snag because as far as I can see, there is no CVS
> tag for what was actually released as 0.91.  The closest seems to be
> Branch-0_91, but there is still a delta relative to what's actually
> in the tarball (see attached).

My dear Mr. Langasek, I really had no idea any of this mattered.  Not
one line of C code changed, just some touch-ups to the README and an
update to the version string.  But you caught me out!  I never committed
those changes:

jklowden@oak[freetds-0.91]$ cvs -n update
M ChangeLog
M README
M configure.ac

First things first:

jklowden@oak[freetds-0.91]$ ./commit |sh
Checking in ChangeLog;
/cvsroot/freetds/freetds/ChangeLog,v  <--  ChangeLog
new revision: 1.3205.2.43; previous revision: 1.3205.2.42
done
Checking in README;
/cvsroot/freetds/freetds/README,v  <--  README
new revision: 1.12.4.1; previous revision: 1.12
done
Checking in configure.ac;
/cvsroot/freetds/freetds/configure.ac,v  <--  configure.ac
new revision: 1.60.2.6; previous revision: 1.60.2.5
done

> Would it be possible to update the release process so that there's an
> explicit tag for each tarball that's published?

Yes, absolutely.  It's something I want to do; you're not the first to
ask.  

> There are also a large number of files present in CVS repository that
> are not included in the tarball; I guess this is just an oversight in
> the 'make dist' target.  I'm happy to fix this up.

Not an oversight at all.  I see no relationship between the tarball and
CVS, other than that the tarball can be generated from CVS.  There's
neither promise nor need of promise that all the files in CVS be in the
tarball.  The promise is that you can build FreeTDS from the tarball,
and that promise is kept.  

That policy both adheres to the license -- all files remain
publicly available in CVS -- and simplifies user's situation, should he
have to investigate a build problem.  He can't be distracted by files
that are inputs to generate source code.  

> (Then there are also the unittest directories, which seem to have no
> relationship between the CVS repo and what's in the release tarball?)

Not sure what you're referring to there.  

> Also, what's the status of the migration from CVS to git?  
...
> if this transition is
> happening soon so I can base my bzr package repos on the git branches
> instead of the CVS.

Use CVS.  

Yours truly has been reluctant to move to git, for the simple reason
that CVS is doing what I want.  Frediano wants to use git, and so do
some downstream, such as yourself.  I'm willing for the sake of the
community.  And I figure I'll learn something, and get well-marked
tarballs in the bargain.  

To those following along at home, let me explain that it's not just
about me, or about my fumbling with git.  The overnight update system
creates a patch if and only if one is needed.  That's complicated by
the fact that the wheels are turning as the determination is made: CVS
changes the keyword strings, and configure.ac needs its string changed
for each tarball generated.  (We don't do that for CVS HEAD, but we
want to, which is why head patches are turned off right now.)  

To use git as a maintainer, I have to redo the overnight scripts using
git.  And I will.  It's just that I've been much more interested lately
in my automaton TDS parser, and haven't been willing to devote a
weekend or two to updating the FreeTDS repository.  

At some point, I'll either succeed or fail with my automaton.  When I
do, I'll either have a bunch of new files to commit, or free time (so
to speak) to devote to git in the wake (so to speak) of my automaton's
demise.  That's the idea, which to this weekend hacker serves as a
plan.  

Finally, Steve, thanks.  Thanks for your work with Debian all these
years. Thanks for including FreeTDS in your distributions.  And thanks
for educating the upstream maintainer about the needs of the packager
and the practice of release engineering.  

Regards, 

--jkl