hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yexi Jiang <yexiji...@gmail.com>
Subject Re: Discussion about guideline
Date Tue, 06 Aug 2013 00:48:26 GMT
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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message