hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chia-Hung Lin <cli...@googlemail.com>
Subject Re: Discussion about guideline
Date Thu, 08 Aug 2013 12:22:48 GMT
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 <edwardyoon@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 <edwardyoon@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 <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
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon

Mime
View raw message