[jira] Commented: (HADOOP-5587) Feature Designs and Test Plans templates in HTLM

["gary murry (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689744#action_12689744 ] 

gary murry commented on HADOOP-5587:
------------------------------------

Original Email:
Begin forwarded message:

> From: Nigel Daley <nd...@yahoo-inc.com>
> Date: February 17, 2009 11:02:07 PM PST
> To: <co...@hadoop.apache.org>
> Subject: Re: Feature Designs and Test Plans
> Reply-To: core-dev@hadoop.apache.org
>
> [let's see if this formatting comes through better...]
>
> [resurrecting an old thread now that I've had time to put together a 
> proposal]
>
> Sounds like folks are agreeing we need design docs and test plans for 
> features, with common sense prevailing on when to apply this rule to 
> smaller features.
>
> So, let me propose some design doc and test plan templates.
>
> Design Doc Template:
> 	• Problem Definition
> 		• what problem does the feature solve?
> 		• why is it needed?
> 	• Use Cases
> 		• sequence of simple steps on how users interacts with the feature
> 	• Interaction with Current System
> 		• does this feature build on an existing feature? if so, how?
> 		• how does the user interact with the new feature from outside the 
> system
> 		• how does the new feature interact within the system
> 	• Requirements
> 		• focus on what functionality must exist and minimize discussion of 
> how that functionality will be implemented
> 		• list items out of scope
> 	• Design
> 		• give a high level description of the implementation
> 		•
> algorithms and/or data-structures involved, this may be in the form of 
> pseudo-code
> 		• failure analysis
> 	• Future Work
> 		• what additional work is related or could be done, but is not 
> included in this design
>
> Test Plan Template:
> 	• Feature(s) Tested: enumerate the feature(s)
> 		• which Jira issue(s)?
> 		• what is the feature?
> 		• what is the externally visible view of the feature?
> 	• Risk Scenarios: enumerate the bad things that could happen in the 
> system that either:
> 		• could be caused by the feature
> 		• could have an effect on the feature
> 	• Test Cases: enumerate all tests in tables
> 		• using table headings Id, Type of Test, Description, Expected 
> Behavior, Is Automated?
> 		• enumerate positive and negative test case types
> 		• include functional, system, scale, and performance test case types
> 		• indicate which tests are automated in JUnit suite
>
> Past Design Doc Examples
> 	• 
> http://issues.apache.org/jira/secure/attachment/12348296/DFSUpgradePro
> posal3.html
>
> Past Test Plan Examples
> 	• https://issues.apache.org/jira/secure/attachment/12373559/PermissionsTestPlan2.pdf
> 	• https://issues.apache.org/jira/secure/attachment/12363605/BlockCrcFeatureTestPlan.pdf
> 	• 
> https://issues.apache.org/jira/secure/attachment/12351299/TestPlan-Hdf
> sUpgrade.html
>
> Some examples requiring the above:
> 	• HADOOP-1700 (file append)
> 	• HADOOP-702 (DFS upgrades)
> 	• HADOOP-3938 (disk quotas)
> 	• HADOOP-372 (input format per dir)
> 	• HADOOP-153 (skip bad records)
>
>
> Thoughts?  Is this something we can all commit to do?
>
> Cheers,
> Nige
>
>
>> Hadoop Committers,
>>
>> The Hadoop project has grown to become a critical platform for many 
>> companies.  As we approach a 1.0 release (perhaps within the next 6
>> months) I think it is time we adopt some more rigor around designing 
>> and testing new features.
>>
>> As committers, we are already given a couple duties that relate to 
>> quality.  Fromhttp://wiki.apache.org/hadoop/HowToCommit :
>>
>>> If a committer reviews a patch they've not authored, and believe it 
>>> to be of sufficient quality, then they can commit the patch, 
>>> otherwise the patch should be cancelled with a clear explanation for 
>>> why it was rejected.
>>>
>>> ...
>>>
>>> Patches should be rejected which do not adhere to the guidelines 
>>> inhttp://wiki.apache.org/hadoop/HowToContribute
>>>  and to thehttp://wiki.apache.org/hadoop/CodeReviewChecklist.  
>>> Committers should always be polite to contributors and try to 
>>> instruct and encourage them to contribute better patches.
>>>
>> These have been a good starting point, but I'd like to propose more 
>> rigor.
>>
>> I propose that before we commit issues marked as "New Feature", they 
>> must have:
>> 1. a design doc attachment
>> 2. a test plan attachment
>> (Templates to be provided for both)
>>
>> I believe these 2 items will enhance the communication, design, and 
>> quality of our new features.
>>
>> Are committers open to adopting these further guidelines?
>>
>> Thanks,
>> Nige
>



> Feature Designs and Test Plans templates in HTLM
> ------------------------------------------------
>
>                 Key: HADOOP-5587
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5587
>             Project: Hadoop Core
>          Issue Type: Wish
>            Reporter: gary murry
>         Attachments: DesignDocTemplate.html, TestPlanTemplate.html
>
>
> This Jira is to address an existing email thread which requested a Feature Design template and Test Plan template in HTML format.  
> Past Design Doc Examples
> http://issues.apache.org/jira/secure/attachment/12348296/DFSUpgradeProposal3.html
> Past Test Plan Examples
> https://issues.apache.org/jira/secure/attachment/12373559/PermissionsTestPlan2.pdf
> https://issues.apache.org/jira/secure/attachment/12363605/BlockCrcFeatureTestPlan.pdf
> https://issues.apache.org/jira/secure/attachment/12351299/TestPlan-HdfsUpgrade.html
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.