Hi Allen,

Thanks for driving this. Just some quick questions:

>>        Removing changes.txt, relnotes.py, etc from branch-2 would be an 
>> incompatible change.  Pushing aside the questions of that document’s quality 
>> (hint: lots of outright lying and missing several hundred jiras), it's 
>> effectively an interface in used by quite a few folks.

Why removing CHANGES.txt  is an incompatible change? Why CHANGES.txt
is an interface? Can you give some examples?

It looks like that the meaning of incompatibility is overloaded -- at
the very least, in
http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Compatibility.html,
compatibility means source and binary compatibility.

At least to me that CHANGES.txt is not part of the contract of
compatibility. It would be great to see this patch to occur in
branch-2.

~Haohui

On Thu, Apr 2, 2015 at 10:12 AM, Allen Wittenauer <a...@altiscale.com> wrote:
>
> On Apr 2, 2015, at 9:51 AM, Karthik Kambatla <ka...@cloudera.com> wrote:
>>>
>>> a) remove CHANGES.TXT from trunk
>>>
>>
>> Removing this from trunk makes it particularly hard to cherry-pick changes
>> from trunk to branch-2. I would gate this on the removal of CHANGES.txt on
>> branch-2 as well, at least until we have some non-future releases off
>> branch-2.
>
>         Removing changes.txt, relnotes.py, etc from branch-2 would be an 
> incompatible change.  Pushing aside the questions of that document’s quality 
> (hint: lots of outright lying and missing several hundred jiras), it's 
> effectively an interface in used by quite a few folks.
>
>         But in reality, I suspect the opposite: removing changes.txt just 
> from trunk will make cherry picks easier.  If you don’t have to update 
> trunk’s changes.txt, you can cherry-pick with no worries about conflict 
> merges on changes.txt in other branches.  Then just update changes.txt in 
> branch-2 manually as you would have done pre- this change anyway.
>
>
>>> b) pre-populate x amount of Hadoop 2.x release data into trunk so that the
>>> auto-indexer can pick it up
>>> c) update the HowToRelease information with, well, how to do releases
>>> based upon these new capabilities
>>>
>>
>> There is a create-release script that likely needs updating.
>>
>
>
>         Yup.  I knew about it (I happen to have it running in another window 
> as I type this), but from what I can see, it’s completely undocumented. :(  
> As I update HowToRelease, I’m going to puts some notes in it about this 
> script.

Reply via email to