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
