hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mai Haohui <ricet...@gmail.com>
Subject Re: IMPORTANT: automatic changelog creation
Date Thu, 02 Apr 2015 18:36:16 GMT
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 <aw@altiscale.com> wrote:
>
> On Apr 2, 2015, at 9:51 AM, Karthik Kambatla <kasha@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.

Mime
View raw message