mahout-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r900702 - in /websites/staging/mahout/trunk/content: ./ developers/how-to-contribute.html
Date Sun, 09 Mar 2014 11:46:49 GMT
Author: buildbot
Date: Sun Mar  9 11:46:49 2014
New Revision: 900702

Log:
Staging update by buildbot for mahout

Modified:
    websites/staging/mahout/trunk/content/   (props changed)
    websites/staging/mahout/trunk/content/developers/how-to-contribute.html

Propchange: websites/staging/mahout/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sun Mar  9 11:46:49 2014
@@ -1 +1 @@
-1575692
+1575693

Modified: websites/staging/mahout/trunk/content/developers/how-to-contribute.html
==============================================================================
--- websites/staging/mahout/trunk/content/developers/how-to-contribute.html (original)
+++ websites/staging/mahout/trunk/content/developers/how-to-contribute.html Sun Mar  9 11:46:49
2014
@@ -221,31 +221,27 @@
   <div id="content-wrap" class="clearfix">
    <div id="main">
     <h1 id="how-to-contribute">How to contribute</h1>
-<p>"Contributing" to an Apache project is about more than just writing code --
+<p><em>Contributing to an Apache project</em> is about more than just writing
code --
 it's about doing what you can to make the project better.  There are lots
-of ways to contribute....</p>
+of ways to contribute!</p>
 <p><a name="HowToContribute-BeInvolved"></a></p>
 <h2 id="be-involved">Be Involved</h2>
-<p>Contributors should join the <a href="https://cwiki.apache.org/confluence/display/MAHOUT/Mailing+Lists%2C+IRC+and+Archives">Mahout
mailing lists</a>
-.  In particular:</p>
+<p>Contributors should join the <a href="/general/mailing-lists,-irc-and-archives.html">Mahout
mailing lists</a>.  In particular:</p>
 <ul>
-<li>The user list (to help others)</li>
-<li>The commit list (to see changes as they are made)</li>
-<li>The dev list (to join discussions of changes)  -- This is the best place
+<li>The <strong>user list</strong> (to help others)</li>
+<li>The <strong>development list</strong> (to join discussions of changes)
 -- This is the best place
 to understand where we are headed.</li>
+<li>The <strong>commit list</strong> (to see changes as they are made)</li>
 </ul>
 <p>Please keep discussions about Mahout on list so that everyone benefits. 
 Emailing individual committers with questions about specific Mahout issues
 is discouraged.  See <a href="http://people.apache.org/~hossman/#private_q">http://people.apache.org/~hossman/#private_q</a>
 .</p>
-<p>You can also <a href="https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=resolution+%3D+Unresolved+AND+reporter+%3D+currentUser%28%29">track
issues that you've raised</a>
- in JIRA.</p>
 <p><a name="HowToContribute-WhattoWorkOn?"></a></p>
 <h2 id="what-to-work-on">What to Work On?</h2>
 <p>What do you like to work on?  There are a ton of things in Mahout that we
-would love to have contributions for.  Data ingestion, data visualization,
-documentation, new algorithms, performance improvements, better tests, etc.
- The best place to start is by looking in JIRA under the Mahout project and
+would love to have contributions for: documentation, performance improvements, better tests,
etc.
+The best place to start is by looking into our <a href="https://issues.apache.org/jira/browse/MAHOUT">issue
tracker</a> and
 seeing what bugs have been reported and seeing if any look like you could
 take them on.  Small, well written, well tested patches are a great way to
 get your feet wet.  It could be something as simple as fixing a typo.  The
@@ -254,17 +250,14 @@ for making changes to the code.  Mahout 
 point, so changes, especially from non-committers, need to be evolutionary
 not revolutionary since it is often very difficult to evaluate the merits
 of a very large patch.  Think small, at least to start!</p>
-<p>Beyond JIRA, hang out on the dev@ mailing list.  That's where we discuss
+<p>Beyond JIRA, hang out on the dev@ mailing list. That's where we discuss
 what we are working on in the internals and where you can get a sense of
 where people are working.</p>
 <p>Also, documentation is a great way to familiarize yourself with the code
-and is always a welcome addition to the codebase and to this Wiki.</p>
-<p>Also, check out the <a href="https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=labels+%3D+MAHOUT_INTRO_CONTRIBUTE">MAHOUT_INTRO_CONTRIBUTE</a>
- items in JIRA, as these have been deemed to be fairly easy to start on.</p>
-<p>Also feel free to jump in on the <a href="https://issues.apache.org/jira/browse/MAHOUT/fixforversion/12318886--juststartingtobefilledin">backlog</a>
- or on a the [next version|https://issues.apache.org/jira/browse/MAHOUT/fixforversion/12316364]</p>
-<p>If you are interested in working towards being a committer, <a href="https://cwiki.apache.org/confluence/display/MAHOUT/How+To+Become+A+Committer">general
guidelines are available online</a>
-.</p>
+and is always a welcome addition to the codebase and this website. Feel free 
+to contribute texts and tutorials! Committers will make sure they are added 
+to this website.</p>
+<p>If you are interested in working towards being a committer, <a href="/developers/how-to-become-a-committer.html">general
guidelines are available online</a>.</p>
 <p><a name="HowToContribute-ContributingCode(Features,BigFixes,Tests,etc...)"></a></p>
 <h2 id="contributing-code-features-big-fixes-tests-etc">Contributing Code (Features,
Big Fixes, Tests, etc...)</h2>
 <p>This section identifies the ''optimal'' steps community member can take to
@@ -276,43 +269,29 @@ against possible future changes).</p>
 don't have the time or resources to do everything outlined on this below
 should not be discouraged from submitting their ideas "as is" per "Yonik
 Seeley's (Solr committer) Law of Patches": </p>
-<blockquote>
-<p>A half-baked patch in Jira, with no documentation, no tests and no backwards compatibility
is better than no patch at all.</p>
-</blockquote>
+<p><em>A half-baked patch in Jira, with no documentation, no tests and no backwards
compatibility is better than no patch at all.</em></p>
 <p>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.</p>
 <p><a name="HowToContribute-Gettingthesourcecode"></a></p>
 <h3 id="getting-the-source-code">Getting the source code</h3>
-<p>First of all, you need the Mahout source code.</p>
-<p>Get the source code on your local drive using <a href="http://lucene.apache.org/mahout/developer-resources.html">SVN</a>
-.  Most development is done on the "trunk":</p>
-<p><code>
-svn checkout <a href="http://svn.apache.org/repos/asf/mahout/trunk">http://svn.apache.org/repos/asf/mahout/trunk</a>
- mahout-trunk
-</code></p>
-<p>Note that committers have to use https instead of http here, but http is
-fine for read-only access to the trunk code.</p>
+<p>First of all, you need to get the <a href="/developers/version-control.html">Mahout
source code</a>. Most development is done on the "trunk".</p>
 <p><a name="HowToContribute-MakingChanges"></a></p>
 <h3 id="making-changes">Making Changes</h3>
-<p>Before you start, you should send a message to the <a href="http://lucene.apache.org/mahout/mailinglists.html">Mahout
developer mailing list</a>
- (Note: you have to subscribe before you can post), or file a bug in [Jira|http://issues.apache.org/jira/browse/MAHOUT]
-.  Describe your proposed changes and check that they fit in with what
-others are doing and have planned for the project.  Be patient, it may take
-folks a while to understand your requirements.</p>
+<p>Before you start, you should send a message to the <a href="/general/mailing-lists,-irc-and-archives.html">Mahout
developer mailing list</a>
+(note: you have to subscribe before you can post), or file a ticket in  our <a href="/developers/issue-tracker.html">issue
tracker</a>.
+Describe your proposed changes and check that they fit in with what others are doing and
have planned for the project.  Be patient, it may take folks a while to understand your requirements.</p>
 <p>Modify the source code and add some (very) nice features using your
 favorite IDE.</p>
 <p>But take care about the following points</p>
 <ul>
-<li>All public classes and methods should have informative <a href="http://java.sun.com/j2se/javadoc/writingdoccomments/">Javadoc
comments</a>
-.</li>
-<li>Code should be formatted according to <a href="http://java.sun.com/docs/codeconv/">Sun's
conventions</a>
-, with one exception:</li>
-<li>indent two spaces per level, not four.</li>
+<li>All public classes and methods should have informative <strong>Javadoc comments</strong>.</li>
+<li>Code should be formatted according to the official <a href="http://www.oracle.com/technetwork/java/codeconventions-150003.pdf"></a>,
with two exceptions:</li>
+<li>indent two spaces per level, not four</li>
+<li>lines can be 120 characters, not 80</li>
 <li>Contributions should pass existing unit tests.</li>
-<li>New <a href="http://www.junit.org">unit tests</a>
- should be provided to demonstrate bugs and fixes.</li>
+<li>New unit tests should be provided to demonstrate bugs and fixes</li>
 </ul>
 <p><a name="HowToContribute-Generatingapatch"></a></p>
 <h3 id="generating-a-patch">Generating a patch</h3>
@@ -323,30 +302,19 @@ contribution.</p>
 <h4 id="unit-tests">Unit Tests</h4>
 <p>Please make sure that all unit tests succeed before constructing your
 patch.</p>
-<p><code></p>
-<p>cd mahout-trunk</p>
-<p>mvn clean test</p>
-<p></code></p>
-<p>After a while, if you see</p>
-<p><code>BUILD SUCCESSFUL</code></p>
-<p>all is ok, but if you see</p>
-<p><code>BUILD FAILED</code></p>
-<p>please, read carefully the errors messages and check your code.</p>
+<p>Run <em>mvn clean test</em>, if you see <em>BUILD SUCCESSFUL</em>
after the tests have finished, all is ok, but if you see <em>BUILD FAILED</em>,

+please carefully read the errors messages and check your code.</p>
 <p><a name="HowToContribute-Creatingthepatchfile"></a></p>
 <h4 id="creating-the-patch-file">Creating the patch file</h4>
-<p>Check to see what files you have modified with:</p>
-<p><code>svn stat</code></p>
-<p>Add any new files with:</p>
-<p><code>svn add src/.../MyNewClass.java</code></p>
-<p>Subversions "add" command only modifies your local copy, so it doess not
-require commit permissions.  By using "svn add", your entire comtribution
+<p>Check to see what files you have modified with <em>svn st</em>, add
new files with <em>svn add src/.../MyNewClass.java</em></p>
+<p>Subversions "add" command only modifies your local copy, so it does not
+require commit permissions.  By using "svn add", your entire contribution
 can be included in a single patch file, without needing to submit a
 seperate set of "new" files.</p>
-<p>Edit the ''CHANGES.txt'' file, adding a description of your change,
-including the bug number it fixes.</p>
-<p>In order to create a patch, just type:</p>
-<p><code>svn diff &gt; MAHOUT-$issuenumber.patch</code></p>
-<p>$issuenumber here should be the number of the JIRA issue the patch is
+<p>Edit the ''CHANGELOG.txt'' file, adding a description of your change,
+including the bug number it fixes. In order to create a patch, just type:</p>
+<p><em>svn diff &gt; MAHOUT-$issuenumber.patch</em></p>
+<p><em>$issuenumber</em> here should be the number of the JIRA issue the
patch is
 supposed to fix. This will report all modifications done on Mahout sources
 on your local disk and save them into the ''MAHOUT-$issuenumber.patch''
 file.  Read the patch file. Make sure it includes ONLY the modifications
@@ -368,47 +336,20 @@ subversion to figure out what's changed 
 </ul>
 <p><a name="HowToContribute-Contributingyourwork"></a></p>
 <h4 id="contributing-your-work">Contributing your work</h4>
-<p>Finally, patches should be attached to a bug report in <a href="http://issues.apache.org/jira/browse/MAHOUT">Jira</a>
-.  If you are revising an existing patch, please re-use the exact same name
-as the previous attachment, Jira will "grey out" the older versions so it's
-clear which version is the newest.</p>
-<p>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 other's suggestions into into your patch if you think they're
-reasonable.  Finally, remember that even a patch that is not committed is
-useful to the community.</p>
+<p>Finally, patches should be attached to a ticket in our <a href="/developers/issue-tracker.html">issue
tracker</a>.  If you are revising an existing patch, please re-use the exact same name
+as the previous attachment, Jira will "grey out" the older versions so it's clear which version
is the newest.</p>
+<p>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 other's suggestions into into your patch if you think they're reasonable.  Finally,
remember that even a patch that is not committed is useful to the community.</p>
 <p><a name="HowToContribute-Review/ImproveExistingPatches"></a></p>
 <h1 id="reviewimprove-existing-patches">Review/Improve Existing Patches</h1>
-<p>If there's a Jira issue that already has a patch you think is really good,
-and works well for you -- please add a comment saying so.   If there's room
-for improvement (more tests, better javadocs, etc...) then make the changes
-and attach it as well.  If a lot of people review a patch and give it a
-thumbs up, that's a good sign for committers when deciding if it's worth
-spending time on the patch -- and if other people have already put in
+<p>If there's a Jira issue that already has a patch you think is really good, and works
well for you -- please add a comment saying so.   If there's room
+for improvement (more tests, better javadocs, etc...) then make the changes and attach it
as well.  If a lot of people review a patch and give it a
+thumbs up, that's a good sign for committers when deciding if it's worth spending time on
the patch -- and if other people have already put in
 effort to improve the docs/tests for a patch, that helps even more.</p>
 <p><a name="HowToContribute-Applyingapatch"></a></p>
 <h2 id="applying-a-patch">Applying a patch</h2>
-<p>From the base directory (assuming that is where the patch is generated
-from), run:</p>
-<div class="codehilite"><pre><span class="n">patch</span> <span
class="o">-</span><span class="n">p</span> 0 <span class="o">-</span><span
class="nb">i</span> <span class="o">&lt;</span><span class="n">PATH</span>
<span class="n">TO</span> <span class="n">PATCH</span><span class="o">&gt;</span>
<span class="p">[</span><span class="o">--</span><span class="n">dry</span><span
class="o">-</span><span class="n">run</span><span class="p">]</span>
-</pre></div>
-
-
-<p><a name="HowToContribute-HelpfulResources"></a></p>
-<h1 id="helpful-resources">Helpful Resources</h1>
-<p>The following resources may prove helpful when developing Mahout
-contributions.  (These are not an endorsement of any specific development
-tools).  Note, these are the same code styles that Lucene and Solr use.</p>
-<ul>
-<li>
-<p><a href="http://svn.apache.org/viewvc/mahout/trunk/buildtools/Eclipse-Lucene-Codestyle.xml?view=co">Eclipse
codestyle.xml file for Mahout's coding conventions, same as Lucene</a></p>
-</li>
-<li>
-<p><a href="http://wiki.apache.org/solr/HowToContribute?action=AttachFile&amp;do=view&amp;target=IntelliJ.codestyle.xml">IntelliJ
IDEA codestyle.xml file for Mahout's coding conventions</a>
- (deprecated - Please don't use this. You are welcome to change this file
-to match the checkstyle and remove this notice)</p>
-</li>
-</ul>
+<p>From the base directory (assuming that is where the patch is generated from), run:</p>
+<p>*patch [--dry-run] -p0 -i <PATH TO PATCH> *</p>
    </div>
   </div>     
 </div> 



Mime
View raw message