hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward J. Yoon" <edwardy...@apache.org>
Subject Re: Discussion about guideline
Date Tue, 06 Aug 2013 01:07:52 GMT
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

Mime
View raw message