Hey, 2008/5/21 Chris Hostetter <[EMAIL PROTECTED]>:
> : I'd tend to disagree: committing the patches to trunk allows widespread > : testing and the chance for wider review of the code to see if it does > : what it should. Only when the code is part of a release is there any > : obligation to a proper lifecycle (ongoing support, deprecation, then > : finally removal). > > True .. but once something is commited it's hard to extract if > people decide they are unhappy with the API/implementation prior to a > formal release. The general philosophy about committing in Solr is > outlined on the wiki... > > http://wiki.apache.org/solr/CommitPolicy Sure, Commit-Then-Review vs. Review-Then-Commit ... but I don't actually think RTC is going to ensure significantly more widespread review since the time burden on other developers to find the issue in JIRA, download the patch, apply the patch, test, respond, then revert the change. Do people really have the time to do that? It's significantly more effort than that to svn update, look at code, and feed back. I prefer detailed discussion on the mailing list (which supports decent threading, quoting etc, unlike JIRA) followed by commit of a trial implementation which can then be refactored. Otherwise there might be a tendency to analysis paralysis. But I'm the new boy here, so I'll STFU and try to help out on the release instead of forcing y'all to rehash old discussions on how to run an open source project ;-) Maybe by the time 1.3 is out the door we'll all be using distributed SCM systems and the discussion will be moot anyway! Andrew. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/
