Re: [Monotone-devel] Status of nvm.stripped

[Markus Wanner]

Hi,

Thomas Moschny wrote:
> Totally agree.

I agree as well. However, we currently have absolutely no coverage for
any library version.

WRT library version checking: it does not make sense to state that we
only support botan 1.8.0 (and not 1.8.1 or 1.8.2). The branch already
features extensive static as well as dynamic version checking and
refuses to work with botan 1.9.x, for example.

> Are we (when combining different versions of the used libraries) to
> expect subtle bugs that eat peoples databases with no one noticing?

Hopefully not, because the used library versions are expected to be
backwards compatible. But theoretically possible, yes.

> I guess most problems will rather arise at compile time or when running
> the test suite. And distributions should run the test suite before
> shipping their builds to the end user. For the Fedora package we surely
> do that.

That does not help much. Any of the libraries could get upgraded without
having to repackage or even recompile monotone. So a mtn compiled
against botan 1.8.0 (hopefully) runs with botan 1.8.3 (once released)
without ever having run the test suite.

> So, I'm in favor of merging this branch earlier rather than later, so
> maybe very soon after releasing 0.42.

Not much happened on that branch since just after 0.41. What's the
reasoning for landing it now?

Don't get me wrong, I'm absolutely for this change. However, it
currently needs porting to and testing on different platforms, not
landing. (And no, I don't believe that landing gets us more time to do
this. It's only hindering us from releasing 0.43, if we didn't get
around doing it.)

Please rather (re)consider landing nvm.dates (and then
nvm.dates.statistics as well), which are IMO ready to land. Or review
Stephen Leake's work and land that.

Regards

Markus Wanner