On Wed, 16 Oct 2002, Geoff Hutchison wrote:
>
> On Tuesday, October 15, 2002, at 01:37 PM, Neal Richter wrote:
>
> > 2. The mifluz devel list is near death, and it doesn't look like
> > anyone
> > is actually using mifluz, or furthering development.
>
> Fine, but that simply does not mean that prior releases were not made
> with active users, developers or testing. There has been much more
> significant testing (on my part included) on the mifluz framework than
> the remainder of the ht://Dig codebase.
I agree in theory. In practice until the new code has been verified to
be acceptable after a successful merge it is suspect.
We hope that it will fix all our problems.. it will be a while before we
confirm this.
> > 5. The current mifluz code merge has problems with constructors and
> > destructors in a library (libhtdig) setting. I would rather help
>
> No offense, but your argument applies here. Why should libhtdig be a
> feature criteria for 3.2.0b4?
I agree, it's not a criteria. I will maintain a separate branch for
that.
> > 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.
>
> Sorry to sound dubious, but speaking of large code merges, you haven't
> submitted patches for me to merge into 3.2.0b4 either. As of yet, I
> haven't tested your zlib WordDB compression or seen if it has
> performance problems relative to 3.2.0b4. Can I claim that your code has
> seen as much user-level testing as 3.2.0b4 snapshots?
Heh. ;-) I'll get you those ASAP.
Zlib is extremely well tested and the changes are a few lines of
code. Giving this as a work around to people who encounter the WordDB
compression bug is a good alternative to hoping that its fixed in a
merged-mifluz codebase.
> I'm somewhat trying to play devil's advocate here. My gut feeling is
> that the mifluz merge should be aimed towards a 3.2.0b5 release and we
> *should* get 3.2.0b4 out the door as stable as possible in the
> near-term. But I'm pretty sure that merging in the new mifluz code is an
> overall win.
I agree in theory. In practice I am motivated to suggest we scale
back what is absolutely necessary in order to get users a new release
faster.
Gilles in particular has voiced frustration over the delay in 3.2
release. And the waste of his time maintaining 3.1.x I'd hate to
continue adding to the pile and further frustrate him.
If we were a company and were risking the speedy completion of a
release by wanting to incorporate a huge chunk of third party code that
needs more work... we'd be in real danger of getting fired.
I guess I see these things:
1. The 3.2 dev process is too open-ended at present
2. The 3.1.x users need a new release
3. The current 3.2beta4 code offers a significant release to users
4. We are in danger of being waist deep in feature-creep quicksand.
If we delay the integration of mifluz and the larger items on your list,
we'll have a tractable set of things to do to get a decent release out
there.
Basically I'm suggesting that for morale purposes alone we do this and
set a goal of pushing a 3.2 release out the door by December.
Next, we make a list and divide it between smaller changes and larger
ones. Smaller ones go into 3.3 (release in March?) and the rest into 4.0.
The development could be semi-parallel at this point.
You may disagree with the "numbers game" here, but I think it would be
good for morale to establish a set of well-reasoned conservative milestones
and meet them in the sort-term.
If we implement a strategy like this and six-months later we look back
and see that we've had 1-2 releases and are moving forward with integration of
large new features/code we'll feel much better vs still being in
feature-creep quicksand.
Here's a proposal
http://ai.rightnow.com/htdig/proposed_schedule.html
Basically I included only things in 3.2 schedule that are necessary to
fix or work around known bugs. Things like Quim's new search frame-work
and the excellent XML-config file feature are in 3.3.
More open-ended things like mifluz merge and STL and Unicode are in 4.0
& 4.1
Also the Zlib-WordDB in 3.2 and More efficient WordDB inverted index are
straight forward and buys us time with the mifluz merge.
Anyway.. I'm sure you're you won't agree on my thoughts on the
mifluz-merge and this is certainly a conservative viewpoint on it. If we
make good progress on the mifluz-merge by the end of the year I'll
withdraw any further objections.
Eh?
Neal Richter
Knowledgebase Developer
RightNow Technologies, Inc.
Customer Service for Every Web Site
Office: 406-522-1485
-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/htdig-dev
