Mailing-List: contact dev-help@hama.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hama.apache.org
Received-SPF: pass (nike.apache.org: domain of yexijiang@gmail.com designates
 209.85.214.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGQgZQTFsMv7LrtS2nn1JAq-vD=wZru2v8xMjS9mrs=BBAK20w@mail.gmail.com>
References: 
 <CA+jdVcwDUqgxYArZ-WAKmH1D1e3edSCCuONvVAFZpUwB3vFY0g@mail.gmail.com>
	<CAGQgZQTFsMv7LrtS2nn1JAq-vD=wZru2v8xMjS9mrs=BBAK20w@mail.gmail.com>
Date: Mon, 5 Aug 2013 20:48:26 -0400
Message-ID: 
 <CAN_uYPjsOtpRaDjxEtaGxRv_Y-dZ++SNcs49t83sFTKFrbN=hA@mail.gmail.com>
Subject: Re: Discussion about guideline
From: Yexi Jiang <yexijiang@gmail.com>
To: "dev@hama.apache.org" <dev@hama.apache.org>
Content-Type: multipart/alternative; boundary=047d7bf187586a05f004e33cc89f

--047d7bf187586a05f004e33cc89f
Content-Type: text/plain; charset=ISO-8859-1

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/

--047d7bf187586a05f004e33cc89f--