Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=message-id:date:from:user-agent:mime-version:to:subject:
	references:in-reply-to:content-type:content-transfer-encoding;
	b=FCVnROrs+32mlHrurDnGXWNtam8tRLP0CrNN3cBHqexGdWIZ6thWHBAUFPmOADAW
Message-ID: <4925AC6F.9040208@yahoo-inc.com>
Date: Thu, 20 Nov 2008 10:29:03 -0800
From: Konstantin Shvachko <shv@yahoo-inc.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: core-dev@hadoop.apache.org
Subject: Re: Feature Designs and Test Plans
References: <5C65FF3A-9844-4C0C-B68D-C26E3458BDE8@yahoo-inc.com>
In-Reply-To: <5C65FF3A-9844-4C0C-B68D-C26E3458BDE8@yahoo-inc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+1 to require design docs and test plans for new features.
--Konstantin

Nigel Daley wrote:
> 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.  From http://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 in 
>> http://wiki.apache.org/hadoop/HowToContribute and to the 
>> http://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
> 
>