Lately I've been spending most of the time I dedicate to Rivet working
on the debianization of it. I'm being helped in the process by Sven
Hoexter, Debian Maintainer (thanks Sven), who checked thoroughly every
commit I did and has been very helpful.
Most if not all the commits I did were restricted to the contents of the
debian/ directory, so I thought as a good thing not to add noise on the
list for commits related neither to the module source nor the Tcl
library (noticeable exceptions are the new distclean targets added to
the Makefile.am and doc/Makefile.am).
Last week I managed to build 2 packages able to pass the basic Debian
test scripts and uploaded them to mentors.debian.net. (To the Debian
users: look up libapache2-mod-rivet if you want to rebuild the packages
on your own). I hoped those commits were the last ones but today Sven
found more incomplete files and wrong information in Rivet that would
set up the packages for an unavoidable rejection by the ftp master (in
the end the business will gain to me a Master in Debian Sciences... :-< )
I realize now that the whole thing is taking much longer than I hoped
and I'm growing uneasy to do more commits to trunk silently. Virtually
I'm locking 'trunk' preventing Damon from adding the new stuff he had
intention to put in Rivet that would require tcl 8.5.
Moreover, while I'm still able to merge the changes into the 2_0 keeping
it aligned to trunk, it has become a senseless way to work and probably
it's time to question the existence of a 2_0 branch as a working space
to be kept open indefinitely with the only purpose to do more 2.0.x releases
My proposal
1) Use the 2_0 branch for the debian development. I will test the debian
build process using tarballs exported from a working copy of 2_0 and
commit the changes to this branch once the package created has been
accepted by Debian.
2) When the PPD (Picky People of Debian) will accept the package the new
2.0.2 will be copied out of 2_0 and this branch abandoned as a branch
from which create tagged releases. The branch will then be reintegrated
into 'trunk' and declared dead.
3) In case a 2.0.3 release (tcl8.4 compatible) will be created copying
it from tags/2.0.2.
3) If Damon wants to throw in the changes that will break tcl8.4
compatibility he can do it in trunk at will.
I don't know what the 1_0 branch was meant for but I consider that
development branch as abandoned.
Sorry for the long message.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
