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 <[email protected]> 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 <[email protected]> wrote: >> How about the current in-progress issues? >> >> >> 2013/8/5 Edward J. Yoon <[email protected]> >> >>> > 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 <[email protected]> >>> 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, [email protected] >> School of Computer and Information Science, >> Florida International University >> Homepage: http://users.cis.fiu.edu/~yjian004/ > > > > -- > Best Regards, Edward J. Yoon > @eddieyoon -- Best Regards, Edward J. Yoon @eddieyoon
