On Friday, October 11, 2002, at 02:38  PM, Neal Richter wrote:

> Giles wrote:
>> stated before, I'm willing to maintain the 3.1.x branch as far as 
>> 3.1.7,
>> which will be a bug-fix release only.  But if 3.2 doesn't get solid 
>> soon
>> (and it's going to take more than my input and Geoff's to do that), I'm
>
> What is your summary of the things that need to be done?  It's been 
> pretty
> solid in my view.
>
> I would propose that we make a SHORT list of things that need to be
> added/fixed ASAP and get it released.  What's on your list?
>
> Lets get a short list together, do the work and move into a kind of
> QA-process where we test for memory leaks/bugs, profile it, and fix 
> bugs.
>
> Then lets break up the new feature ideas into a wish list with balance
> between efficiency improvements and new feature for a 3.3 release.
>
> The mifluz merge is so large in my mind that it ought to be part of a 
> 4.0
> release.

You're welcome to your opinion. But let's start out with your "short 
list."

* Switch to Quim's qtest framework: absolutely crucial. The bugs that 
Sinclair sees with punctuation, etc. are due to a pretty creaky htsearch 
system. Moreover, the current code isn't very amenable to expansion, new 
query syntaxes, or wrapping (in a library or another CGI-like system)
* Migrate defaults.cc to new XML system: in retrospect, I think this is 
high-priority for 3.2 so the binaries don't have to carry around all 
those extra strings.
* Memory improvements to htmerge and other httools: Current 
implementations load the entire wordlist or document list into memory, 
rather than "walking" record-by-record.
* Forward-porting 3.1.6 improvements to htsearch, etc.
* Documentation improvements as mentioned in STATUS file.
* Current htsearch "collections" code is really convoluted and should 
likely be rewritten. IMHO, this is legitimately 3.2-priority since it's 
been a feature in previous 3.2 betas and there are users reliant on this.
* "basic regex" or "wildcard" fuzzy type: Current regex fuzzy isn't 
particularly user-friendly.
I haven't even consulted the sf.net bug tracker or features 
tracker--these are just off the top of my head.

No, it's not too bad if there was some serious development effort like 
there was shortly before 3.1.0. But as Gilles pointed out, it simply 
cannot happen in a reasonable time frame without additional development 
manpower.

As for the mifluz merge, I don't quite understand your apparent bias 
against it. 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. The mifluz code that I've 
merged in has a fair amount of external code review and testing from 
other users. Why has it taken so long to merge--basically I just haven't 
had the ability to block out time to do it in one fell swoop so it's 
dragging on forever.

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.

-Geoff



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/htdig-dev

Reply via email to