Mailing-List: contact dev-help@hama.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hama.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAN_uYPjsOtpRaDjxEtaGxRv_Y-dZ++SNcs49t83sFTKFrbN=hA@mail.gmail.com>
References: 
 <CA+jdVcwDUqgxYArZ-WAKmH1D1e3edSCCuONvVAFZpUwB3vFY0g@mail.gmail.com>
	<CAGQgZQTFsMv7LrtS2nn1JAq-vD=wZru2v8xMjS9mrs=BBAK20w@mail.gmail.com>
	<CAN_uYPjsOtpRaDjxEtaGxRv_Y-dZ++SNcs49t83sFTKFrbN=hA@mail.gmail.com>
Date: Tue, 6 Aug 2013 10:07:52 +0900
Message-ID: 
 <CAGQgZQS5FxT5Q8wDD97B=OoUx8_VL7wtkyr_3JoC5HRrR55OdA@mail.gmail.com>
Subject: Re: Discussion about guideline
From: "Edward J. Yoon" <edwardyoon@apache.org>
To: dev@hama.apache.org
Content-Type: text/plain; charset=UTF-8

I personally would like to cut a release 0.6.3 after solve the
HAMA-789 and HAMA-717 issues. Because, there are people who want to
run Hama cluster on Hadoop 2.0 environment like me.

I think we can move rest current issues into 0.7 roadmap. As we know,
the only critical issues in core BSP project, are now memory
efficiency and FT system. And, BSP-based ML algorithm library, query
language projects can began in earnest.

On Tue, Aug 6, 2013 at 9:48 AM, Yexi Jiang <yexijiang@gmail.com> wrote:
> How about the current in-progress issues?
>
>
> 2013/8/5 Edward J. Yoon <edwardyoon@apache.org>
>
>> > First, each release, or between different releases, would have tasks
>> > included. Among tasks there might have priority between those tasks or
>> > a task may block one or more tasks. So how do we determine priority of
>> > tasks or that between several releases? An naive thought is by voting;
>> > however, issues may not be clear for every participants. In that case,
>> > voting may defer more important tasks.
>>
>> I think we can follow current guide line.
>>
>> "Every ideas for improvements, new features, and suggestions are
>> recommended to be discussed in polite terms before implementation on
>> the dev@ list, and then its decisions must be listed on our RoadMap
>> page. In simple improvement or bug type issues, you can skip the
>> discussion and report directly on JIRA."
>>
>> And then, we can cut a release according to the Roadmap.
>>
>> > a.) when a patch is submitted, at least 2 reviewers should help review
>> > source code.
>> > b.) the patch creator should describe e.g. execution flow/ procedure
>> > in a higher/ conceptual level.
>> >
>> > Reviewers then can cooperate review parts of the code in patch (tool
>> > may help in this stage). Some review points such as (java) doc and
>> > test cases should be included.
>> >
>> > - Test cases
>> > Each patch should have test cases that at least capture the main
>> > logical flow. And the tests is recommended not to bound to external
>> > dependencies so that time spent on testing can be reduced.
>> >
>> > - Doc (Java doc or wiki)
>> > Class should at least describe what it is, or its main logic flow. Or
>> > at lease write down the mechanism in wiki. Method fields that is not
>> > self-explanatory would be good to have doc explaining its purpose or
>> > its execution mechanism.
>>
>> +1
>>
>> On Mon, Aug 5, 2013 at 11:33 PM, Chia-Hung Lin <clin4j@googlemail.com>
>> wrote:
>> > As hama community grows, it seems that it is good to have a guideline
>> > so that participants can follow and cooperate more smoothly. Therefore
>> > I would like to discuss about this, and please share your opinions so
>> > that we can improve the process.
>> >
>> > Below are some issues popping up on my head.
>> > - roadmap prioritization
>> > - development work flow
>> >
>> > First, each release, or between different releases, would have tasks
>> > included. Among tasks there might have priority between those tasks or
>> > a task may block one or more tasks. So how do we determine priority of
>> > tasks or that between several releases? An naive thought is by voting;
>> > however, issues may not be clear for every participants. In that case,
>> > voting may defer more important tasks.
>> >
>> > Second, a few subtopics are listed as below:
>> >
>> > - Code review
>> > Though a commit section is described, it is not clear how the
>> > procedure will be practised. My thought is
>> >
>> > a.) when a patch is submitted, at least 2 reviewers should help review
>> > source code.
>> > b.) the patch creator should describe e.g. execution flow/ procedure
>> > in a higher/ conceptual level.
>> >
>> > Reviewers then can cooperate review parts of the code in patch (tool
>> > may help in this stage). Some review points such as (java) doc and
>> > test cases should be included.
>> >
>> > - Test cases
>> > Each patch should have test cases that at least capture the main
>> > logical flow. And the tests is recommended not to bound to external
>> > dependencies so that time spent on testing can be reduced.
>> >
>> > - Doc (Java doc or wiki)
>> > Class should at least describe what it is, or its main logic flow. Or
>> > at lease write down the mechanism in wiki. Method fields that is not
>> > self-explanatory would be good to have doc explaining its purpose or
>> > its execution mechanism.
>> >
>> > Just some ideas I have at the moment. Will add more if I find others.
>> > And we should keep improving it when necessary. Please add your points
>> > if you think some are missing, or remove some that is not needed.
>> >
>> > [1]. How to commit - Review
>> https://wiki.apache.org/hama/HowToCommit#Review
>>
>>
>>
>> --
>> Best Regards, Edward J. Yoon
>> @eddieyoon
>>
>
>
>
> --
> ------
> Yexi Jiang,
> ECS 251,  yjian004@cs.fiu.edu
> School of Computer and Information Science,
> Florida International University
> Homepage: http://users.cis.fiu.edu/~yjian004/


-- 
Best Regards, Edward J. Yoon
@eddieyoon