[Solr Wiki] Update of "HowToContribute" by ErickErickson

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "HowToContribute" page has been changed by ErickErickson:
https://wiki.apache.org/solr/HowToContribute?action=diff&rev1=98&rev2=99

Comment:
Added a few instructions on building 'dest' and 'server' and a clarification about patch naming and uploading

  Note that committers have to use [[http://apache.org/dev/committers.html#commit-403|https]] instead of http here, but http is fine for read-only access to the code.
  
  If you prefer you could use the [[https://github.com/apache/lucene-solr|GitHub]] mirror instead. Note that the drop-down lets you select "trunk" or "branch_5x" (among others).
+ 
+ === Building the first time ===
+ 
+ {{{
+ cd your_checkout_dir/solr
+ Issue any of the following commands. 
+ 
+ 'ant server' will build a runnable Solr (note, 'ant example' is the target pre 5.x)
+ 
+ 'ant dist' will build the libraries you might want to link against from, say, a SolrJ program.
+ 
+ 'ant package' will build files like 'package/solr-5.2.0-SNAPSHOT-src.tgz' which are standard distributions you can install somewhere else just like an official release.
+ 
+ 'ant test' will run all of the unit tests. NOTE: this takes quite a while.
+ }}}
  
  == Exporting to a local repository ==
  When making larger scale (please, try to keep your patches as small as humanly possible) changes, or when working in a team, you might want to be able to keep track of what you are doing locally. One way of doing so, is exporting to a local SVN repository.
@@ -185, +200 @@

  
  This will report all modifications done on Solr sources on your local disk and save them into the ''SOLR-NNN.patch'' file.  Read the patch file.   Make sure it includes ONLY the modifications required to fix a single issue.
  
- Note the ''SOLR-NNN.patch'' patch file name.  Please use this naming pattern when creating patches for uploading to JIRA.  Once you create a new JIRA issue, note its name and use that name when naming your patch file.  For example, if you are creating a patch for a JIRA issue named SOLR-123, then name your patch filename SOLR-123.patch.  If you are creating a new version of an existing patch, use the existing patch's file name.  JIRA will automatically "gray out" the old patch and clearly mark your newly uploaded patch as the latest.
+ Note the ''SOLR-NNN.patch'' patch file name.  Please use this naming pattern when creating patches for uploading to JIRA.  Once you create a new JIRA issue, note its name and use that name when naming your patch file.  For example, if you are creating a patch for a JIRA issue named SOLR-123, then name your patch filename SOLR-123.patch.  If you are creating a new version of an existing patch, use the existing patch's file name. 
  
  Please do not:
  
@@ -203, +218 @@

   * try to provide a unit test that shows a bug was indeed fixed or the new functionality truly works
  
  == Contributing your work ==
- Finally, patches should be attached to a bug report in [[http://issues.apache.org/jira/browse/SOLR|Jira]].  If you are revising an existing patch, please re-use the exact same name as the previous attachment, Jira will "gray out" the older versions so it's clear which version is the newest.
+ Finally, patches should be attached to a bug report in [[http://issues.apache.org/jira/browse/SOLR|Jira]].  If you are revising an existing patch, please re-use the exact same name as the previous attachment. JIRA will automatically "gray out" the old patch and clearly mark your newly uploaded patch file as the latest (it'll be the colored link). You'll see multiple copies of your patch if you've named them identically, and this is preferred as it preserves the history of the patch which can come in handy. Since the most recent one is the only one not gray, we always know which one to use.
  
  Please be patient.  Committers are busy people too.  If no one responds to your patch after a few days, please make friendly reminders.  Please incorporate others suggestions into your patch if you think they're reasonable. Remember that even a patch that is not committed is useful to the community. Supply first patch as early as possible and updated patches as often as possible during your work. This helps the rest of the community and committers to start understanding, help shaping, commenting on etc. your work throughout the entire process. Supplying a patch does not necessarily mean that it is complete and ready to be committed, it might also just be a way of communicating your idea and progress.