Matthew,
I understand your concern. However, the fact is I reviewed many patches and gave comments to most of them in the past. If you believe I am the one who not letting good patch come in, feel free to grab them and apply it. Or even start another one base on all current patch. As I already said in the past, if people going to implemented a feature, I am going to review it, and I did. I don't reject patch without reason. Many patches are in fact committed to the cvs. You personally have the QueryResult.absolute() function implemented. You still owe me a test case for it, don't you? I think that you and me are both limited by the time is clear. You suggest that I should have regression test for bugs people found, I take effort to enforce the policy and write test case myself. But, where is the test case you contributed?? I believe it is my own personal choice to decide what part of Castor I spend my effort on. So does other people. More than that, I do take my own time to review patches and explains things to them. I am not hiding any symptoms. But, whenever I said it is the limitation and we don't have time, a chains of email saying what to improve is pop up like now. All those idea are good if I have time. I want to full time job on castor too. But, it is not what happening. All symptoms have been repeating many times in the mailing list. On the other hand, I am being very frank that I don't think I have time to make refactoring in anytime soon, didn't I? Am I the one who is unrealistic, or you? Expecting complaining one in a while and things will be done? Expecting things can be solved easily? Expecting the current architecture have no limitation? Expecting each problem can be fixed one by one? Expecting all problem can be solve without change a large amount of code? Expecting everyone have unlimited time? Expecting I have already know all solutions to all problems? Matthew, I think I had enough discussion with you about those things, I hope it will come to an end. All code is on your hand, do whatever you want. If you keep complaining like these, you will make nothing happens, but make yourself the last one I want to share information with. Thomas -----Original Message----- >From: Matthew Baird [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, April 24, 2002 10:16 AM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Castor JDO Status > >Your posting outlines the major problem. Search the list, >the typical exchange looks like this: > >someone: I want to fix the cache to allow distributed mode. >(or more generic, I want to change castor to support X feature) >thomas: wait for big refactoring. > >Let's be realistic, that big refactoring is probably never coming. >If it's not, let's publish the ideas and let someone else try to work >on it. I'm all for fixingb the problem rather than hiding the symptoms. > >I know I've personally not had things committed, or not even >bothered submitting them because of the big mysterious refactoring >that is coming down the pipe sometime in the future. > >m > >-----Original Message----- >From: Ned Wolpert [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, April 24, 2002 10:04 AM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Castor JDO Status > > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >> From: Matthew Baird <[EMAIL PROTECTED]> >> Date: Wed, 24 Apr 2002 08:48:09 -0700 >> >> Something that really held up development was; Everytime a change was >> requested/proposed, someone would talk about the big refactoring and >> architecture change that was coming (Someone else mentioned this point >> already). I don't think this refactoring/arch change is coming for a LONG >> time, unless Thomas and the exolab declassify the design documents/plans for >> the change and donate them to the community so someone else can make the >> change. >> >> I see this as a survival move for Castor, as there are starting to be other >> more actively developed projects sneaking up on them (OJB Anyone?) >> >> so..... FREE THE INFORMATION! Let us peek at the proposed plans for JDO and >> let us pick it up and continue! > >Heh... "You say you wanna revoultion... yeah yeah you know... we don't >wanna change the world..." > >Sorry... didn't mean to 'burst' out into song... couldn't help >myself. (and I especially apologize if I got the lyrics wrong) > >There are really two issues here that people have hit on. The first >is that the future direction of Castor is somewhat unknown. The >second is that enhancements are slow in coming. Of course, things >like better documentation may help the flood of requests on the >mailing list, but really those are almost secondary. The community >that has built up around Castor is really the focus point, and how new >users get most of their help. > >I cannot really address these two main issues myself; though I'm a >committer, I don't work for Exolab and can't speak on the direction >for Castor. And as far as enhancements go, I tend to focus on getting >Castor JDO with PostgreSQL being a good replacement for >TopLink/Oracle. This makes my personal focus fairly narrow. However, >one of the issues that I directly am trying to fix is being able to >manually remove objects from the cache. As Thomas mentioned, this is >more tricky than it sounds since there are deadlock scenarios that can >occur during this. I've even seen deadlocks occur in my current >production usage of Castor with lazy collections in certain >cases... and rare timing issues exist as well even without lazy >collections. > >The need for the refactoring is obvious, considering these issues I >mentioned. What to refactor is tricky, and fairly complex. (See the >code base if you don't believe me. :-) However, the real problem is >time; Exolab/intalio started this project, and gets to decide >direction. But regardless of the long term direction, there are >things we can do now to, in a sense, assist with the 'big >refactoring'. For me, getting the cache more 'open' is a must. >(Especially if we want a distributed cache) But to do this requires >us to refactor just enough so that we understand and dealt with these >timing issues. So, let me make a request to the Castor JDO >community... for those who have a good understanding of threading >issues and have some understanding of the internals for Castor source, >examing the caching system. Look at the past posts made by Thomas and >others about deadlock problems in the current system. And lets review >and discuss where these deadlocks may occur and start working on test >cases that show them. To me, this is the best way to go forward. > >(And for those who can't understand the source code, or haven't solved >deadlock conditions, you can help by simply testing/using Castor. >The more its used, to more we'd be likely to find the problems.) > > >- -- > >Virtually, >Ned Wolpert <[EMAIL PROTECTED]> > >D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.6 (GNU/Linux) >Comment: Public key at http://www.keyserver.net > >iD8DBQE8xuV5iysnOdCML0URAlhUAJ9QxA+nMv1eZzaL2wMDoJoaM5uTcACdGoha >STsOCmT321M2Ye9lGqotCiU= >=+uj8 >-----END PGP SIGNATURE----- > >----------------------------------------------------------- >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
