On Dec 10, 2004, at 2:22 PM, Daniel John Debrunner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
RPost wrote:
somethingJack 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 EXCEPT
proves to be important then we should revisit this.
I certainly agree with this approach. The first priority is to getthat 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....
geir
Dan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBufduIv0S4qsbfuQRArnpAKC/+mF0mqcKAlVfbyol+DpgihMBMwCfUwkZ bkHwm6zG0V06CNLGw6UfVdM= =Ctr9 -----END PGP SIGNATURE-----
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
