hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raghu Angadi <rang...@yahoo-inc.com>
Subject Re: add incompatible flag to Jira
Date Tue, 18 Mar 2008 21:14:47 GMT

I think our current definition of a 'Incompatible Change' is so broad 
that it is not useful for a user. I never understood why a protocol 
version change should be in that list (I know, technically it is 

Also automated release notes can never come close to human generated 
release notes, however incomplete the human generated version is.

+1 if this is just a guideline and Hadoop requires a (not very long) 
human generated end-user friendly release notes.


Nigel Daley wrote:
> I'm underwhelmed by the response to this thread.  Any other 
> input/opinions on how we track incompatibilities and create meaningful 
> release notes?
> Nige
> On Mar 12, 2008, at 12:15 AM, Nigel Daley wrote:
>> On Mar 11, 2008, at 12:17 PM, Doug Cutting wrote:
>>> Nigel Daley wrote:
>>>> 1. an incompatible checkbox
>>> This really only passes the buck, doesn't it?
>> Ya, it passes it to the right people - the submitter and reviewer as 
>> opposed to the committer (who is currently responsible for determining 
>> if an issue goes in the INCOMPAT section of CHANGES.txt).  We also 
>> need to provide guidelines on what may be considered an incompatible 
>> change.
>>>> 2. a release note text box
>>> Shouldn't folks just include CHANGES.txt message in the patch?  
>>> That's what I've always encouraged, but few are ever provided.  
>>> Perhaps Hudson can bounce patches that don't touch CHANGES.txt?
>>> Both these would make sense if we intend to abandon CHANGES.txt and 
>>> use them instead.  Is that your intent?
>> No, I think we need CHANGES.txt (or some equivalent) that lists ALL 
>> the changes in the release (as opposed to the release notes that only 
>> list the important changes).  I'm told, too, that it's also convenient 
>> to have a complete list of changes IN the workspace so that a 
>> developer can quickly see what has been recently committed.  So I 
>> think CHANGES.txt stays.  My proposal is to add an additional files 
>> (release notes) that is auto generated from the new field in Jira.
>> Nige

View raw message