Re: tetex-* CVS repository on klecker?
Thinking off the top of my head here (and remember that I'm not
quite a CVS wizard, although I've started using it pretty
extensively for some things)...
Sources
=======
I'm not sure how different the Debian package sources are from
what Thomas Esser releases, but we'd probably be better off having
the source in CVS match what we use for packaging. Doing so would
mean that any new upstream sources would have to be massaged into
a checked-out version of our sources and then be checked in.
The other option would be to keep things more like Thomas's stuff,
and have scripts that would build source trees for releases from
the archive, which I would think would be a lot messier.
Tags & Branches
===============
Probably at the least we would want to be tagging Debian releases
and any upstream releases separately. (So we'd have, for example,
INITIAL CHECKIN, DEBIAN tetex-base 1.0.2+20011202-2, UPSTREAM
20020305, DEBIAN tetex-base 1.0.2+20020305-1, DEBIAN tetex-base
1.0.2+20020305-2, etc.)
We might also want to have branches, so that we can maintain the
teTeX that's released with woody separately from the work being
done for the next release. (We'd create the branch when the
version of teTeX that's being released is done, and continue work
on the main tree thereafter, but could check out the woody branch
to fix bugs in woody without changing other files.)
Changelogs
==========
I was also thinking about what we should be doing for changelogs
(for individual files that we modify), but hadn't come to any real
conclusion. We could either
1. Create a new version in debian/changelog, and log changes
there (with entries like
* texk/tetex/fmtutil: patched to fix format generation
problem (closes: #xxxxxx) [cmc@debian.org]
* texk/tetex/fmtutil.8: modified to reflect changes in fmtutil
script [cmc@debian.org]
) as well as in individual files that are changed, with
whoever makes the final determination about making a release
being responsible for checking over those notes before
finalizing the changelog
2. Just log changes in the logs for the individual files, and
use a tool such as cvs2cl (in the cvs2cl package) to
generate changelogs that are then included in the
debian/changelog file
I'm not sure which is better, although (2) is easier (because you
only need to log changes in one place). We'd probably have to do
some experimentation with cvs2cl to get output to match what we'd
want, but it looks to be pretty powerful and flexible, so if it
can't do what we want, we could either fix it or dump its output
as XML and manipulate that with another script of our own.
CMC
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
C.M. Connelly cmc@debian.org SHC, DS
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Reply to: