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 ShawnHeisey
Date Fri, 27 Oct 2017 16:07:42 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 ShawnHeisey:
https://wiki.apache.org/solr/HowToContribute?action=diff&rev1=114&rev2=115

Comment:
Updated the list of branches to reflect reality since the 7.0 release.  Clean up old branches/tags
and other outdated info.

  
  Solr can always use more/better documentation targeted at end users.  The [[https://lucene.apache.org/solr/guide/|Reference
Guide]] is the official documentation and has recently been migrated from Confluence to AsciiDoctor
(June, 2017 as of Solr 6.6), for background see: [[https://lucidworks.com/2017/05/05/reimagining-the-solr-reference-guide|Reimagining
the Solr Reference Guide]]
  
- The biggest change is that documentation now follows the same process as code changes: 
+ The biggest change is that documentation now follows the same process as code changes:
   * get the source
   * edit the reference guide (*.adoc files in ...solr/solr-ref-guide/src)
   * raise a JIRA and submit a patch.
@@ -45, +45 @@

  A half-baked patch in Jira, with no documentation, no tests
  and no backwards compatibility is better than no patch at all.
  }}}
- Just because you may not have the time to write unit tests, or cleanup backwards compatibility
issues, or add documentation, doesn't mean other people don't. Putting your patch out there
allows other people to try it and possibly improve it.  ''That said'' if you want to maximally
increase the chances that your patch will get the attention it deserves, leave no stone unturned
so that committers are more interested in your patch. 
+ Just because you may not have the time to write unit tests, or cleanup backwards compatibility
issues, or add documentation, doesn't mean other people don't. Putting your patch out there
allows other people to try it and possibly improve it.  ''That said'' if you want to maximally
increase the chances that your patch will get the attention it deserves, leave no stone unturned
so that committers are more interested in your patch.
  
  == Getting the source code ==
  First of all, you need the Solr source code.<<BR>>
@@ -66, +66 @@

  }}}
  The <branch> part of the command above needs to be replaced by something concrete
- the "code line" you want to get.  Examples, and how to interpret what they mean:
  
-  * master: Working towards the eventual 7.0 release. This is the main center for development,
it's not really a branch.  Releases are never made from master, they are only made from the
stable development branch.
+  * master: Working towards the eventual 8.0 release. This is the main center for development,
it's not really a branch.  Releases are never made from master, they are only made from the
stable development branch.
-  * branch_6x: The current stable development branch for the next stable 6.x version.
+  * branch_7x: The current stable development branch for the next stable 7.x version.
-  * releases/lucene-solr/5.5.3: When a new version is fully released, the lucene_solr_x_x
branch is copied to a tag which represents the source code for that specific release.
+  * lucene_solr_7_1: The branch from which 7.1.x versions are built.  This is a minor release
branch.
+  * branch_6x: The previous stable development branch for 6.x releases.
-  * releases/lucene-solr/4.10.3: When a new version is fully released, the lucene_solr_x_x
branch is copied to a tag which represents the source code for that specific release.
+  * releases/lucene-solr/7.1.0: When a new version is fully released, the branch_x_x branch
is copied to a tag which represents the source code for that specific release.
-  * history/branches/lucene-solr/lucene_solr_4_10: When branch_4x was removed and 4.x moved
to maintenance mode, all 4.x development moved to this branch.  There is never a guarantee
that a point release will ever be made after the x.x.0 version is released.
-  * history/branches/lucene-solr/lucene_solr_3_6: When branch_3x was removed and 3.x moved
to maintenance mode, all 3.x development moved to this branch.
+  * branch_6_6: When 7.0.0 was released and 6.x went into maintenance mode, all maintenance
development moved to this branch, because it was the last minor release branch in the 6.x
line.  Only fixes for major bugs and security issues are made to versions in maintenance mode.
+  * branch_5_5: When 6.0.0 was released and 5.x went into maintenance mode, all maintenance
development moved to this branch, because it was the last minor release branch in the 5.x
line.  Normally with the release of 7.0.0 all development would cease on the 5.x code, but
a temporary exception was made for this branch because of a security issue, and version 5.5.5
was released *after* the 7.0.0 release to fix that problem.
  
- Git SHA can be used to obtain branches and tags from their parents.  For example, revision
1394844 on history/branches/lucene_solr_4_0 corresponds to the official 4.0.0 release, so
if you add "-r 1394844" to the command line above using branches/lucene_solr_4_0 for <branch>,
you will get the code corresponding to 4.0.0.  You can also just do a checkout of releases/lucene-solr/4.0.0
to get the same code.
+ Every git commit has a SHA hash value.  In many cases, this value can be used to obtain
specific branches and tags from their parents.  For example, the git sha value of df4de29b55369876769bb741d687e47b67ff9613
on branch_6_6 corresponds to the official 6.6.2 release, so if you check out that commit from
branch_6_6 you will get exactly the same code as the release tag for 6.6.2.  In cases where
the release has already been announced, you can also just do a checkout of the release tag,
releases/lucene-solr/6.6.2 is an example.
  
- Most development is done on "master" and then backported to the other active branches. 
At some point in the future, a branch_6x will be created and master will be updated to reflect
a 7.0 version. 
+ Most development is done on "master" and then backported to the any other active branches
that will receive the same change.  At some point in the future, a branch_8x will be created
and master will be updated to reflect a 9.0 version.
- 
- 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.
  
  === Working with GitHub ===
- If you prefer you could use the [[https://github.com/apache/lucene-solr|GitHub]] mirror
instead. Note that the drop-down lets you select "master" or "branch_5x" (among others).
+ If you prefer you could use the [[https://github.com/apache/lucene-solr|GitHub]] mirror
instead. Note that the drop-down lets you select "master" or "branch_7x" (among others).
- We accept GitHub Pull Requests (PR). To submit one, first fork the project, then make changes
in a feature branch which you push to GitHub and use as the basis for the PR. PRs should be
''linked'' to a JIRA issue in the appropriate project here: [[http://issues.apache.org/jira/browse/SOLR|Solr
Jira]] or here: [[http://issues.apache.org/jira/browse/LUCENE|Lucene Jira]]. To link your
PR to the Jira issue simply include the Jira issue id in the title of the PR (first create
the Jira issue if one doesn't exist). 
+ We accept GitHub Pull Requests (PR). To submit one, first fork the project, then make changes
in a feature branch which you push to GitHub and use as the basis for the PR. PRs should be
''linked'' to a JIRA issue in the appropriate project here: [[http://issues.apache.org/jira/browse/SOLR|Solr
Jira]] or here: [[http://issues.apache.org/jira/browse/LUCENE|Lucene Jira]]. To link your
PR to the Jira issue simply include the Jira issue id in the title of the PR (first create
the Jira issue if one doesn't exist).
  
  (!) '''Note about old forks:''' If you had an existing GitHub fork from before January 23rd
2016, then it will no longer list as "forked from" the official `apache/lucene-solr` project,
meaning that PRs will not go to the Lucene project. Technically this is because the old `apache/lucene-solr`
GitHub repo was delete and then re-added during the git switch, causing all forks to choose
another "parent" project. The only fix for this is to delete your fork on the GitHub website
and re-fork from the correct project.
  
@@ -93, +92 @@

  
  {{{
  cd your_checkout_dir/solr
- Issue any of the following commands. 
+ Issue any of the following commands.
  
  'ant server' will build a runnable Solr (note, 'ant example' is the target pre 5.x)
  
@@ -104, +103 @@

  'ant test' will run all of the unit tests. NOTE: this takes quite a while.
  }}}
  
- NOTE: If your build hangs when building and especially on a "resolve" step, it's probably
because there are left over lock files in your ivy directory (often because you crtl-c'd during
a build). To fix this navigate to your .ivy2 directory and delete all of the "*.lck" files
in the tree. For *nix operating systems, issue a command similar to: 
+ NOTE: If your build hangs when building and especially on a "resolve" step, it's probably
because there are left over lock files in your ivy directory (often because you crtl-c'd during
a build). To fix this navigate to your .ivy2 directory and delete all of the "*.lck" files
in the tree. For *nix operating systems, issue a command similar to:
  {{{find . -name "*.lck" | xargs rm}}}
  
  
@@ -207, +206 @@

  
  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. 
+ 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:
  
@@ -259, +258 @@

  $ patch -p1 -i name of the patch --dry-run
  }}}
  
- (notes: 
+ (notes:
     --dry-run just pretends to apply a patch, so you can see if it would succeed or fail.
 Remove --dry-run to *really* apply the patch
     -p1 may need to be -p0 for svn-generated patches that should be rare going forward.)
  

Mime
View raw message