Re: duplication in client/ruby/solrb/solr ?
On 1/3/07, Erik Hatcher <[EMAIL PROTECTED]> wrote: On Jan 3, 2007, at 8:18 PM, Chris Hostetter wrote: > I don't really get Ruby or Rails, so maybe i'm missing something > about why > you need another copy of these files -- but couldn't they be copied > into > place by an ant target instead of commiting duplicate copies? I wanted to lock in a version of Solr to avoid it being a moving target. I'm not quite sure I understand what you mean about copying using Ant. Ant isn't involved in the Ruby world (unless we develop some custom request handlers or something like that, specific to the Ruby stuff). Might labs.apache.org make sense for this project? -Mike
Re: duplication in client/ruby/solrb/solr ?
: > place by an ant target instead of commiting duplicate copies? : : I wanted to lock in a version of Solr to avoid it being a moving : target. I'm not quite sure I understand what you mean about copying : using Ant. Ant isn't involved in the Ruby world (unless we develop : some custom request handlers or something like that, specific to the : Ruby stuff). i ment as part of a new ant target "setup-ruby" or something that could copy the neccessary files into the needed locations (much the way "ant example" currently does) but if your goal is to have a locked down version of solr and to allow people to cheeck out client/ruby and have a self contained sandbox to play with then i understand why you did it this way. : with the desired configuration. I don't envision having the entire : Solr application under the Ruby code permanently, mainly for folks to : jump into it and help out as easily as possible. that sounds fine to me ... i just wanted to clarify why they were all there. -Hoss
[jira] Created: (SOLR-95) simplification of solr_server.rb
simplification of solr_server.rb Key: SOLR-95 URL: https://issues.apache.org/jira/browse/SOLR-95 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Environment: Darwin Kernel Version 8.8.1 Reporter: Ed Summers Priority: Minor Attachments: solr_startup_simpification.diff solr_start() was using a system call to start solr, which resulted in three separate processes that needed to be killed with a process group id. This required solr_start() to disassociate itself from the parent process with setsid, and lookup the subprocesses' parent id. using exec() instead of system() makes this complexity go away fortunately. Also the solr_server.rb was renamed to test_helper.rb as it is likely to contain other methods/classes for clearing the index, etc... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-95) simplification of solr_server.rb
[ https://issues.apache.org/jira/browse/SOLR-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Summers updated SOLR-95: --- Attachment: solr_startup_simpification.diff > simplification of solr_server.rb > > > Key: SOLR-95 > URL: https://issues.apache.org/jira/browse/SOLR-95 > Project: Solr > Issue Type: Improvement > Components: clients - ruby - flare > Environment: Darwin Kernel Version 8.8.1 >Reporter: Ed Summers >Priority: Minor > Attachments: solr_startup_simpification.diff > > > solr_start() was using a system call to start solr, which resulted in three > separate processes that needed to be killed with a process group id. This > required solr_start() to disassociate itself from the parent process with > setsid, and lookup the subprocesses' parent id. > using exec() instead of system() makes this complexity go away fortunately. > Also the solr_server.rb was renamed to test_helper.rb as it is likely to > contain other methods/classes for clearing the index, etc... > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: duplication in client/ruby/solrb/solr ?
On Jan 3, 2007, at 8:18 PM, Chris Hostetter wrote: Erik: doing my first "svn update" since you started working on the flare stuff, i noticed a lot of files commited into client/ruby/solrb/ that seem to be duplicates of other files from the repository ... client/ruby/solrb/solr actually seems to be a duplicated copy of example with some minor changes to the schema.xml and solrconfig.xml ... all of the jetty jars are commited into client/ruby/solrb/solr/ext/, there's even a client/ruby/solrb/solr/webapps/solr.war I don't really get Ruby or Rails, so maybe i'm missing something about why you need another copy of these files -- but couldn't they be copied into place by an ant target instead of commiting duplicate copies? I wanted to lock in a version of Solr to avoid it being a moving target. I'm not quite sure I understand what you mean about copying using Ant. Ant isn't involved in the Ruby world (unless we develop some custom request handlers or something like that, specific to the Ruby stuff). My consideration was primarily for those that will svn checkout from client/ruby and below, and being able to have Solr up and running easily. There will at least be custom configuration for Solr with solrconfig.xml and schema.xml involved in the Ruby effort. I'm open to suggestions for improvement, if there is a cleaner way to allow folks trying this out to easily bootstrap into a Solr instance with the desired configuration. I don't envision having the entire Solr application under the Ruby code permanently, mainly for folks to jump into it and help out as easily as possible. Erik
Re: Is Solr ready for graduation?
On 1/3/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: : +1 from me to starting the discussion, and +1 for graduating. ditto: +1 for starting the process (not sure if i get a vote in on the actual "graduation" question :)) Yes, current committers get a vote on whether we should go for graduation at this point :-) Of course, we value everyones opinion for all votes held on solr-dev, not just committers so anyone can feel free to add their 2 cents. -Yonik
duplication in client/ruby/solrb/solr ?
Erik: doing my first "svn update" since you started working on the flare stuff, i noticed a lot of files commited into client/ruby/solrb/ that seem to be duplicates of other files from the repository ... client/ruby/solrb/solr actually seems to be a duplicated copy of example with some minor changes to the schema.xml and solrconfig.xml ... all of the jetty jars are commited into client/ruby/solrb/solr/ext/, there's even a client/ruby/solrb/solr/webapps/solr.war I don't really get Ruby or Rails, so maybe i'm missing something about why you need another copy of these files -- but couldn't they be copied into place by an ant target instead of commiting duplicate copies? -Hoss
[jira] Resolved: (SOLR-94) added solr startup/shutdown to test task
[ https://issues.apache.org/jira/browse/SOLR-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved SOLR-94. -- Resolution: Fixed Assignee: Erik Hatcher Committed, with the addition of port change. Thanks, Ed! > added solr startup/shutdown to test task > > > Key: SOLR-94 > URL: https://issues.apache.org/jira/browse/SOLR-94 > Project: Solr > Issue Type: New Feature > Components: clients - ruby - flare > Environment: os x >Reporter: Ed Summers > Assigned To: Erik Hatcher > Attachments: solr_start_stop.patch > > > This patch allows the rake test task to start a solr server before running > tests, and shutting it down when the tests are complete. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Is Solr ready for graduation?
: +1 from me to starting the discussion, and +1 for graduating. ditto: +1 for starting the process (not sure if i get a vote in on the actual "graduation" question :)) -Hoss
Re: Is Solr ready for graduation?
Hi, I'd say definitely ask Lucene first. (And in general ask the accepting TLP first, before asking the Incubator). +1 from me to starting the discussion, and +1 for graduating. Yoav On 1/3/07, Yonik Seeley <[EMAIL PROTECTED]> wrote: What do people think? As you may know, graduation is not so much about code maturity/quality as it is about community (in addition to making sure all the legal IP issues are covered). The primary hurdle that Solr faced starting from a closed-source project was building a diverse community (including independent committers). Another recent Incubator recommendation was to make a release, to show we knew the process and to uncover any potential IP or licensing issues. With the release of Solr 1.1, we've now covered that base as well. The next steps would be to get approval from both the Incubator PMC and the Lucene PMC (the order is fuzzy, but this http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator "the Incubator PMC SHALL provide a recommendation to the TLP that the Podling is ready to escalate." suggests that it's the Incubator that should go first). *But*, the incubation checklist suggests otherwize: "If graduating to an existing PMC, has the PMC voted to accept it?" http://incubator.apache.org/projects/solr.html The latter makes more sense to me, so I'd vote to ask the Lucene PMC first if we decide we are ready. -Yonik
[jira] Updated: (SOLR-94) added solr startup/shutdown to test task
[ https://issues.apache.org/jira/browse/SOLR-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Summers updated SOLR-94: --- Attachment: solr_start_stop.patch > added solr startup/shutdown to test task > > > Key: SOLR-94 > URL: https://issues.apache.org/jira/browse/SOLR-94 > Project: Solr > Issue Type: New Feature > Components: clients - ruby - flare > Environment: os x >Reporter: Ed Summers > Attachments: solr_start_stop.patch > > > This patch allows the rake test task to start a solr server before running > tests, and shutting it down when the tests are complete. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-94) added solr startup/shutdown to test task
added solr startup/shutdown to test task Key: SOLR-94 URL: https://issues.apache.org/jira/browse/SOLR-94 Project: Solr Issue Type: New Feature Components: clients - ruby - flare Environment: os x Reporter: Ed Summers This patch allows the rake test task to start a solr server before running tests, and shutting it down when the tests are complete. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Is Solr ready for graduation?
What do people think? As you may know, graduation is not so much about code maturity/quality as it is about community (in addition to making sure all the legal IP issues are covered). The primary hurdle that Solr faced starting from a closed-source project was building a diverse community (including independent committers). Another recent Incubator recommendation was to make a release, to show we knew the process and to uncover any potential IP or licensing issues. With the release of Solr 1.1, we've now covered that base as well. The next steps would be to get approval from both the Incubator PMC and the Lucene PMC (the order is fuzzy, but this http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator "the Incubator PMC SHALL provide a recommendation to the TLP that the Podling is ready to escalate." suggests that it's the Incubator that should go first). *But*, the incubation checklist suggests otherwize: "If graduating to an existing PMC, has the PMC voted to accept it?" http://incubator.apache.org/projects/solr.html The latter makes more sense to me, so I'd vote to ask the Lucene PMC first if we decide we are ready. -Yonik
