I had hoped my "Victory" thread would have sparked more discussion on
the subject of whether the suite of tests was an appropiate default
inclusion in source RPMs, and the difficulty involved in building
Subversion. I'm a new member of your community - so for all I know
you've discussed this to death already.
However, the discussion seems to have settled on whether I should or
should not have attempted to build the source RPM as root (my position
is now that I should not have, but that I had been building source RPMs
that way for years - and that a week's worth of hair-pulling was too
great a penalty to pay for this oversight - that the RUNNING of apache
within the build process makes Subversion a rather unusual beast and
that some method for warning the builder might be appropriate).
More interesting to me are these questions:
Is it appropriate to put what are essentially developer unit tests into
a source package such that they are run by default? Or should the user
of such a package be entitled to assume that it would not have been
released if all such tests had not already passed (assuming a properly
set up environment - which can be tested within the source rpm). At
most, I would think, these tests are relevant to the packager of such
RPMs.
I think we may have a confusion here between environment-checking tests
and developer unit tests, and that we are trying to make one set of
tests developed for the second purpose also serve the first. And this
DOES have consequences - it drives users away from using wanting to use
Subversion. Or it leads to loose talk such as "RH 9.0 is not supported
by subversion".
Speaking of which, another related point is this: Has the Subversion
development team targeted a minimum set of system requirements?
i.e. "Subversion supports the following platforms Windows 2K, XP,
solaris xxx, RedHat Linux > x.x, Debian > x.x. Also required are
Apache > x.x, etc." It still seems a little strange to me that I had
to upgrade my RH9 system with various patches developed for Fedora,
etc. Finalizing a set of minimum requirements for the foreseeable
future would reassure me that I will not have to go through such
trouble with the next subversion release.
In the Jakarta-commons-net project where I am a committer we only
recently dropped support for Java JDK 1.1. (And we only bumped the
minimum level to 1.2). We very deliberately forced ourselves to write
code that was now suboptimal to preserve the contract we had with our
users. Does subversion have such a contract? I think if it did, it
would put to rest some of this "ready for prime time" controversy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 11 20:21:59 2005