> On May 12, 2016, at 12:20 PM, Chris Nauroth <cnaur...@hortonworks.com> wrote:
>
> Hello Allen,
>
> The intent is not for this rule to override other compatibility rules,
> such as the important CLI output rule. It's also not intended to give us
> free reign to change existing toString() implementations without due
> diligence. If a patch changes an existing toString() implementation that
> already goes out to the shell or any other form of external serialization,
> then the patch needs to be declined. (I concur that relying on toString()
> like this should never be done, and I'd encourage us to fix any
> occurrences we find.)
The problem is that we as a community do a terrible job on following
the compatibility guidelines when it comes to CLI output. Because while this
maybe true:
> Instead, the intent is to advertise to Java API consumers that toString()
> output may evolve freely, and therefore we recommend against writing Java
> code that depends on that output format.
… what’s going to happen is people are going to assume that because
toString is now considered Unstable, all output will be considered Unstable by
way of mental short cut. There have been many, many instances over the past
year or two where even long time PMC members have claimed CLI output was
already Unstable/outside the scope of the compatibility guidelines and I just
see this re-inforcing that (incorrect) world view.
> HDFS-9732 is a good example of how to handle this. I didn't explicitly -1
> it, but I did call out the CLI compatibility problem and recommend how to
> change the patch so that it preserves compatibility.
>
> Does this help address your concerns, or is the full code audit the only
> thing that would convince you to lift your -1?
No, because “perception is reality”. If we want to make toString
Unstable, then we need to be very clear as to which toStrings are Unstable and
which aren’t. This isn’t a universal rule without doing some legwork.
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
