lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Update of "HowToContribute" by ErickErickson
Date Fri, 24 Apr 2015 18:12:21 GMT
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.
  

Mime
View raw message