Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 aw@altiscale.com does not designate 209.85.192.176 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: IMPORTANT: automatic changelog creation 
From: Allen Wittenauer <aw@altiscale.com>
In-Reply-To: 
 <CAHpOOhEJ-yNDiUZDdW+M3GRr5zwo61cHLQLO1nuttNet9mxSgg@mail.gmail.com>
Date: Thu, 2 Apr 2015 12:13:29 -0700
Cc: "yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>,
 hdfs-dev@hadoop.apache.org,
 "mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <61DED805-ED1A-454F-AD4F-FBC8C564261E@altiscale.com>
References: <96BCB599-C298-4126-994A-E6C6BA5682E5@altiscale.com>
 <CALwhT97MNfDWGsHJ2a-padsj1gU6OzAPBjDcRBj85dEiKjDnFw@mail.gmail.com>
 <BE545A5B-9F22-4B78-8FF4-E2541F19CA82@altiscale.com>
 <CAHpOOhEJ-yNDiUZDdW+M3GRr5zwo61cHLQLO1nuttNet9mxSgg@mail.gmail.com>
To: common-dev@hadoop.apache.org


On Apr 2, 2015, at 11:36 AM, Mai Haohui <ricetons@gmail.com> wrote:

> Hi Allen,
>=20
> Thanks for driving this. Just some quick questions:
>=20
>>>       Removing changes.txt, relnotes.py, etc from branch-2 would be =
an incompatible change.  Pushing aside the questions of that document=92s =
quality (hint: lots of outright lying and missing several hundred =
jiras), it's effectively an interface in used by quite a few folks.
>=20
> Why removing CHANGES.txt  is an incompatible change? Why CHANGES.txt
> is an interface? Can you give some examples?

	With my end user ops hat on, for years I'd often run scripts =
over CHANGES.TXT to pull key things in releases including to get extra =
metadata that wasn=92t in that file and reformat for my users to digest. =
 (especially since the release notes weren=92t published with the =
release tar and=97let=92s be honest--were mostly indecipherable heaps of =
crap to the point that even the RM=92s never bothered to really look at =
them...) CHANGES.txt was useful to get the base dataset, esp in the days =
before JIRA=92s REST interface.

	It is/was, in essence, an interface.

> 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/Co=
mpatibility.html,
> compatibility means source and binary compatibility.

	FWIW, removing relnotes.py is definitely covered by that =
document.

> 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.

	But yes, I mean beyond that.  It=92s a =91de facto=92 standard =
given how many people use it for critical information about what we=92ve =
released.  This is about managing user expectations and not just what=92s =
convenient for us.  You know, that whole community that we always =
mention but seem to stomp all over.  Just because we CAN do something =
doesn=92t mean we SHOULD.

	An excellent example of this is the HADOOP_OPTS variable.  I=92d =
LOVE LOVE LOVE to kick it to the curb.  It=92s the source of a LOT of =
end user bugs and problematic areas in the shell code.  During the =
rewrite +  the above rules, I had the opportunity and bylaws standing to =
do so.  But I didn=92t because it=92d just flat out break too much =
stuff, known and unknown.

	It=92s ok to be conservative when it comes to change.