Re: Discussion about guideline
It seems that our release requirement fits into continuous integration where software is frequently released. In current workflow, though we can decide what to be included and released in the roadmap. The release may still be deferred even 90% of issues are solved because the rest 10% is still not yet accomplished. With continuous integration (IIRC) the software is released frequently when a new feature is resolved, resulting in the reduced release cycle, and that problems can be solved a bit easier because change is small. If this is the case, it might be good for us adapting to CI; and we can schedule what (relative small) patches to be released in order. On 6 August 2013 09:16, Edward J. Yoon edwardy...@apache.org wrote: I mean, we can move most current issues to 0.7 and start to comply with our new development-process. On Tue, Aug 6, 2013 at 10:07 AM, Edward J. Yoon edwardy...@apache.org wrote: 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 yexiji...@gmail.com wrote: How about the current in-progress issues? 2013/8/5 Edward J. Yoon edwardy...@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 cli...@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
Discussion about guideline
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
Re: Discussion about guideline
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 cli...@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
Re: Discussion about guideline
How about the current in-progress issues? 2013/8/5 Edward J. Yoon edwardy...@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 cli...@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, yjian...@cs.fiu.edu School of Computer and Information Science, Florida International University Homepage: http://users.cis.fiu.edu/~yjian004/
Re: Discussion about guideline
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 yexiji...@gmail.com wrote: How about the current in-progress issues? 2013/8/5 Edward J. Yoon edwardy...@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 cli...@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, yjian...@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
