Personally, I think it's a great step *forward* to see such a list of items/issues/change requests/bugs/'unidentified problems/etc. in one place ... 8-). Though what I just said hopefully highlights the problem as well. Naturally, we all seem to disagree on the severity of the issues outlined below (not to mention the ones not mentioned at all). I think we should take Thomas' list and make it more complete.
Completeness for me is defined as trying to categorize the problems along the line of some of the categories mentioned above, assess things such as risk (of a possible patch having negative side effects), cost (time it takes), progress (work started, progress made, etc.) and then ... and only then ... take it from there. For example, it's not enough to just say ... 3/ Foreign key as part of primary key I think that we have seen (too) many emails on castor-dev asking questions about this bug (is it really a bug?), and still we have not made any progress on this. Progress in the sense that we do not know whether it really is a bug (i.e. is Castor meant to support these kind of relationships?), whether anybody has already identified where the problem could be (e.g. FieldMolder, and the problem only surfaces when executing OQL queries that traverse such relationships), etc. In other words, we need to get more structured, and this implies that the likes of Thomas (and others) need to share what they already know. It's not enough to just know that there's a problem, and that it might take x months of man-time to fix this (and that's after some other stuff had been refactored). This 'hidden' knowledge needs to made visible, put into one place ... if I e.g. knew that the problem has already been identified, I (we as a team here) could start debugging things much more effectively. Any opinions on what's the best way to go about this, and more importantly, would we have the commitment of the current committers ? Regards Werner Matthew Baird wrote: > the list you put together is GREAT! > > now we need a status from key developers on who's working on what, and > what's open to be solved. > > thanks for the information, Thomas. > > m > > -----Original Message----- > From: Thomas Yip [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 24, 2002 5:38 PM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Castor JDO Status > > Matthew, > > Well, I am not agreeing everything on what you summarized. > > For the part I agree, it is not something new. I suspect each > issue have been discussed in the past in the mailing list. > > Anyway, if such a summary is what users ask for, I see no reason > not to doing it more frequently. > > For the feature freeze, I am hoping a freeze too. However, it very > depends on how long we expect the freeze to be, (how long we > expect it can be finished). It haven't been very successful as you > mentioned. On the other hand, each addition developer requires > more effort on communication. He need to accumulate enough from > the existing codebase, before we communicate to him and make him > know what to change. Knowledge on Castor JDO requires developer > to take some time to accumulate, not to be understood all at once. > > Whatever performance concern is big issue depending on how > a user use Castor. I can remember 10 more features that users claim > they will abandon Castor if it is not implemented right the way. > 1/ Uni-directional relationship support > 2/ Polymorphism collection > 3/ Foreign key as part of primary key > 4/ Long transaction without depending on cache > 5/ Cache purging > 6/ Solve 4K BLOL limitations > 7/ Distributed cache > 8/ Self reference relationship (object link to objects of the same type) > 9/ Loading without extensive SQL join (*the* performance limitation) > 10/ Relationship with attribute > 11/ Cascade delete of "independent" object > 12/ OQL Enhancements > 13/ QueryResult got garbage collected > > For the deadlock problem, I don't remember when did a discussion > like taken place. I tend to believe it is reasonably stable. Unless > it can be identified more precisely, it might be a non "first-priority". > > I will try to get my view of your other points in the summary. But, I > guess time is up today. > > At last, I don't agree it worth to fed me up. > But, it may be just a subjective and biased opinion ;-) > > Thomas > > >Summary: > >- There are committers other than Thomas. (Oleg, Ned, Bruce...) > >- Thomas doesn't have a lot of time to work on CastorJDO (we all respect > that), but still wants to be involved in it's future (?) > >- Ned is working on cache eviction and mostly postgres issues > >- The big refactoring is not documented, so it should be up to some members > of the community to figure something out. > >- Patches to be committed require test cases. > >- We need to find the deadlock issues ASAP. > >- Performance is a major concern. > >- improve documentation. > >- multiple requests for a CastorJDO Developers list. > >- as Werner mentioned, no real roadmap for CastorJDO (what has been > identified, and what is being worked on). > >- Thomas doesn't like me anymore :) > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
