Re: [htdig-dev] Re: 3.2 Stability (was [htdig-members] reasons for objecting to LGPL change)

[Neal R. <ne...@ri...>]

> As for the mifluz merge, I don't quite understand your apparent bias
> against it.

  1.  I'm a fairly conservative Software Engineer.  I believe in tractable
      sets of reasonable size changes.  This is pretty large.  In my
      experience the idea of beta versions is to fix bugs, new features
      and major code rework is avoided if possible.

  2.  The mifluz devel list is near death, and it doesn't look like anyone
      is actually using mifluz, or furthering development.

  3.  Loic is AWOL, and we have to certainty, other than what he told the
      this group, that the current mifluz works as advertized.  It sounds
      great, but there is no proof or support for the assertions of
      feature improvement.

  4.  How certain are we that these changes are going to make 3.2beta5
      MORE stable than the current beta?

  5.  The current mifluz code merge has problems with constructors and
      destructors in a library (libhtdig) setting.  I would rather help
      the group fix bugs and cleanup code in the current 3.2 than
      burn time fixing those problems in the near-term.

  6.  It has performance problems.

I'm suspicious of starting down a road of swallowing the complete Mifluz
in the near-term.  There are alot more unknowns in merging in mifluz than
fixing other issue first.

If Loic were around and the development list not dead I would be less
suspicious.

The list of feature improvements looks great, and it will be good to get
the merges in.  In my opinion the process of doing that should be that we
get a working merge (which you are making great progress on) and doing a
kind of feature verify and some reasonable unit testing.

This process has many unknowns and I'd hate to hold up the release for it.

My past experience in importing alot of new code like this is that it's
always harder then it seems that there are lots of bugs.


> Let's pretend I was considering upgrading the Sleepycat DB
> code to version 4.2.x from the current 3.1.x. There are a ton of changes
> there too, but I wouldn't be particularly concerned since I know there's
> external code review and plenty of testing.

  Apples vs Oranges to me.  BerkelyDB is very well used and well tested...
by several orders of magnitude more than the current Mifluz and a couple
orders more than HtDig.

 The idea of moving from 3.2beta4 to 3.2beta5 with the list of
changes above seems like alot!  With the changes above,
a case can be made that not only would the code differ significantly
with the previous 3.2betas, it also has a load of new features.

New features late in the release aren't always a good idea.

---------

You're the development leader, and I'll help accomplish the list you
posted.

My input is to ask if we might be better off making a short list of
absolutely necessary bug-fixes for 3.2beta4 and release it soon.

Part of it is a moral thing.  Sometimes when a release is floundering and
taking too long, it's better to draw a line and say we're going to fix
these bugs and get it out the door.

The other part is this important question: Does the current 3.2beta4 +
bug-fixes + 3.1.x improvements offer significant improvement to the 3.1.x users?

If it does then we are harming them in the short-term by delaying the release to
implement lots of new features and import code with many unknowns.

My experience with the current snapshots is very positive.  I've had few
problems and the indexing it self is pretty solid, especially with the new
zlib WordDB compression.

I've sent gigabytes of text through this code and the memory leaks are not
in the critical class.

> The mifluz code that I've
> merged in has a fair amount of external code review and testing from
> other users.

  Can you say that it has had as much as the average HtDig release?  HtDig
is MUCH more active then mifluz has ever been.

> Most of the "ht://Dig" modifications in terms of number of lines of
> patch are simply upgrades in the build environment--moving to
> autoconf-2.5x and newer versions of automake, libtool, etc. These need
> to be done before any 3.2 release.

  True.  And they are good changes to the build env.

  I don't have a good feeling for what 3.1.x users want in 3.2 and if they
are willing to wait for lots of changes to the current 3.2beta or would
rather have a reasonable release soon.

  The other question is if you compare 3.1.x with 3.2beta4 + your list
above I personally believe that the changes are so pervasive and
substantial that the release needs to be called "4.0" just to give it
enough credit ;-).


  Thanks.

Neal Richter
Knowledgebase Developer
RightNow Technologies, Inc.
Customer Service for Every Web Site
Office: 406-522-1485