See: http://wiki.apache.org/solr/HowToContribute
It outlines how to get the code, how to work with patches, how to set up IntelliJ and Eclipse IDEs (links near the bottom?). There are formatting files for both IntelliJ and Eclipse that'll do the right thing in terms of indents and such. Legal issues aside, you don't to be very compulsive about cleaning up the code before posting the first patch! Just let people know you don't consider it ready to commit. You'll want to open a JIRA to attach it to. People often put in //nocommit in places they especially don't like, and the "precommit" ant target takes care of keeping these from getting into the code. People are quite happy to see hack, first-cut patches. You'll often get suggestions on approaches that may be easier and nobody will complain about "bad code" when they know that _you_ don't consider it submittable. Google for "Yonik's law of half-baked patches". One thing that escapes people often... When attaching a patch to a JIRA, just call it SOLR-####.patch, where #### is the JIRA number. Successive versions of the patch should have the _same_ name, they'll all be listed and the newest one will be "live". It's easier to know what is the right patch that way. No big deal either way. Best, Erick On Mon, Feb 3, 2014 at 8:25 AM, Greg Walters <greg.walt...@answers.com> wrote: > The code I wrote is currently a bit of an ugly hack so I'm a bit reluctant to > share it and there's some legal concerns with open-sourcing code within my > company. That being said, I wouldn't mind rewriting it on my own time. Where > can I find a starter kit for contributors with coding guidelines and the > like? Spruced up some I'd be OK with submitting a patch. > > Thanks, > Greg > > On Feb 3, 2014, at 10:08 AM, Mark Miller <markrmil...@gmail.com> wrote: > >> You should contribute that and spread the dev load with others :) >> >> We need something like that at some point, it's just no one has done it. We >> currently expect you to aggregate in the monitoring layer and it's a lot to >> ask IMO. >> >> - Mark >> >> http://about.me/markrmiller >> >> On Feb 3, 2014, at 10:49 AM, Greg Walters <greg.walt...@answers.com> wrote: >> >>> I've had some issues monitoring Solr with the per-core mbeans and ended up >>> writing a custom "request handler" that gets loaded then registers itself >>> as an mbean. When called it polls all the per-core mbeans then adds or >>> averages them where appropriate before returning the requested value. I'm >>> not sure if there's a better way to get jvm-wide stats via jmx but it is >>> *a* way to get it done. >>> >>> Thanks, >>> Greg >>> >>> On Feb 3, 2014, at 1:33 AM, adfel70 <adfe...@gmail.com> wrote: >>> >>>> I'm sending all solr stats data to graphite. >>>> I have some questions: >>>> 1. query_handler/select requestTime - >>>> if i'm looking at some metric, lets say 75thPcRequestTime - I see that each >>>> core in a single collection has different values. >>>> Is each value of each core is the time that specific core spent on a >>>> request? >>>> so to get an idea of total request time, I should summarize all the values >>>> of all the cores? >>>> >>>> >>>> 2.update_handler/commits - does this include auto_commits? becuaste I'm >>>> pretty sure I'm not doing any manual commits and yet I see a number there. >>>> >>>> 3. update_handler/docs pending - what does this mean? pending for what? for >>>> flush to disk? >>>> >>>> thanks. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://lucene.472066.n3.nabble.com/need-help-in-understating-solr-cloud-stats-data-tp4114992.html >>>> Sent from the Solr - User mailing list archive at Nabble.com. >>> >> >
