-Re: First Commit : Suggestions
Grant Ingersoll 2012-02-24, 19:37
Forgot to mention, when you commit something attached to an issue, cite the JIRA issue in the commit message, as in svn ci -m "MAHOUT-XXX: blah, blah, blah"
On Feb 24, 2012, at 12:31 PM, Paritosh Ranjan wrote:
> Dmitriy, Grant,
> Thanks for the suggestions. I will try to incorporate the best practices with time.
> On 24-02-2012 17:08, Grant Ingersoll wrote:
>> On Feb 24, 2012, at 12:11 AM, Paritosh Ranjan wrote:
>>> I would like to do some small, not so risky commit soon ( hours/days, depends on when the code is ready ) to get used to the commit process.
>> Usually we start by adding your name to the website, but I think that is all on the wiki now, so no commit needed! https://cwiki.apache.org/MAHOUT/who-we-are.html
>>> I could not find any document on how its done in Apache.
>>> I will :
>>> a) Do a build without skipping junit tests
>>> b) If build is successful, then commit it in svn repository (https://svn.apache.org/repos/asf/mahout/trunk) using my Apache Id and password ( Using eclipse or some svn utility ).
>>> c) I hope that CI is already in place and the build will be triggered herehttps://builds.apache.org/job/Mahout-Quality/. I will keep on eye on it so that it does not fail.
>>> d) If it fails, fix it. And then start again from point "a".
>>> Is this how it should be done in Apache? If not, please tell.
>> Yep. I'd add in, check to see if there are docs to be updated. Not always easy, but useful. As Dmitry mentioned, many of us use Git via http://git.apache.org.
>> Ted sent along his Git workflow which I find works quite well and makes it easy to keep track of which issue you are working on:
>> From your cloned area:
>> git checkout trunk ; git checkout -b MAHOUT-foo
>> make changes, commit, change, commit.
>> git checkout trunk; git svn rebase ; git checkout MAHOUT-foo ; git rebase trunk
>> Patch for posting to JIRA:
>> git diff trunk --no-prefix
>> Commit to SVN:
>> git rebase trunk --interactive
>> git checkout MAHOUT-foo ; git svn dcommit
>> Also, if it is a bigger patch that encompasses more than a class or two, then best practice is to either do review board or upload a patch to JIRA to solicit comments. If you think you are ready to commit on something big, the usual protocol is to note on JIRA something to the effect of "I plan to commit this in a day or two". That gives the rest of us some time to review given many of us are spread out around the globe. If you don't hear from anyone in that time frame, then go ahead and commit. Lazy consensus is the norm so don't read any meaning into no one commenting on a particular patch.