> > > > > > Looks like this variable size stuff will be the first new feature
> > > > > > for 6.4 then, eh? :)
> > > > >
> > > > >         What is the chance of having this ready by Friday?  Still would
> > > > > give us 3weeks of debugging...
> > > > 
> > > > Well, it's OK to leave _one_ feature for v6.4. Bruce is probably 
> > > > tired of typing the feature list :)
> > > > 
> > > > Also, we still have a few loose ends for v6.3. But, I'll bet Darren's stuff can
> > > > go in and not affect anything if we run using the current block size.
> > > 
> > > Great chance of having it by Friday if not sooner.  I'll get on it tonite.
> > > 
> > > Wasn't sure where the line in the sand was for "adding features" vs "fixing bugs."
> > 
> > I think Marc is getting softer on this issue.  [Ducks head]
> 
> 	Moi?  Never...some ppl have shown over time a...dedication towards
> fixing any bugs they introduce in a *very* timely manner *grin*  A little
> leeway, as appropriate, tends to reap large rewards for all
> parties...specially if we can help improve disk space usage by providing
> the ability to tailor disk block size used :)

The variable block size stuff won't be done by tonite.  Something I've done in
the tape sorting routines is causing a core dump during the constraints regression
test and I haven't been able to track it down the last two evenings.

Sorry about that folks.  I'm going to keep on it, but I wouldn't feel too
comfortable putting in the beta any later than now.

darrenk

Fri, 6 Feb 1998 15:18:13 -0500
darrenk@insightdist.com (Darren King)
Re: [HACKERS] Variable block size...