db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <g...@gluecode.com>
Subject Re: Features - Quick or correct??
Date Mon, 13 Dec 2004 14:29:46 GMT

On Dec 10, 2004, at 2:22 PM, Daniel John Debrunner wrote:

> Hash: SHA1
> RPost wrote:
>>> Jack Klebanoff wrote:
>>> I wanted to make an initial implementation that is simple, handles 
>>> both
>>> INTERSECT and EXCEPT, and that fits into the current Derby
>>> implementation fairly easily. If the performance of INTERSECT or 
>>> proves to be important then we should revisit this.
>> I certainly agree with this approach. The first priority is to get
> something
>> that works
>> as easily and simply as possible.
> I'm not completely convinced this is the correct approach. While it is
> good to have the functionality (and maybe more importantly the tests)
> quickly, first impressions count. So if we (the Derby community) 
> produce
> correct but slow features, it will be hard to shake that image.

Well, no - not for the main development trunk in svn.  I think that 
sucky releases are a problem, but people should expect very little w/ 
the main development trunk in terms of features.  Yes, it should 
compile, yes, it should run, but production-grade performance?  I don' 
think so.

> Contributors & committers should be encouraged to discuss design ideas
> with the list early rather than once they have coded them up.

Yes, but sometimes code talks very well, and it also gives people who 
don't want to slog through email trails a quick view of the idea, and a 
chance to improve.

A good thing about partial or inefficient implementations in main trunk 
is that it can act as flypaper for community members - people will come 
and pitch in to (forgive the cliché...) "scratch an itch".

I may be uninterested in following the dev list in general, but if 
there is some feature I need, and it's part way done, it's much easier 
for me to 'hook in' and get going.  Sometimes a basic framework for 
something lets a developer get started a lot easier than a green field.

> It's also hard for me to tell with various contributions if the
> contributor thinks the feature is complete, or it's an incremental step
> to the fully completed feature.

Ask him or her :)

> I think the incremental step is a great
> way to go, but only if it's identified as that, and the future steps 
> are
> listed so the contributor or someone else can address them. Then it's
> also easy to discuss which of those steps are essential before a 
> feature
> is considered ready for production release.

Fair enough - yes, it's key that you track stuff that way....


> Dan.
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQFBufduIv0S4qsbfuQRArnpAKC/+mF0mqcKAlVfbyol+DpgihMBMwCfUwkZ
> bkHwm6zG0V06CNLGw6UfVdM=
> =Ctr9
Geir Magnusson Jr                                  +1-203-665-6437

View raw message