[
https://issues.apache.org/jira/browse/HDFS-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555690#comment-13555690
]
Suresh Srinivas commented on HDFS-4362:
---------------------------------------
bq. So your argument is like the old "if a tree falls in a forest, and no one
is there, does it make a sound?"
Actually that is your argument :-) If an incompatible change does not affect
any one, is it an incompatible change? I say it is.
bq. What's the purpose of labeling it if no one cares?
The purpose is clearly to say, the wire protocol change is incompatible. The
second part, this may not affect if one is using public interfaces or DFSClient
is to alleviate the concern and indicate that they should not see any issues.
bq. Doesn't it just dilute the "incompatible changes" section of our release
notes with information that no one cares about?
We have handful of these. So it should not dilute the value of of the section.
There are many types of incompatible changes today. API, wire protocol, logs,
semantic behavior, even log changes. Users take a look at the list of changes.
If it is of no concern to them, they disregard it.
By this argument our changes.txt is replete with things that does not matter to
users at all. Some of them are very specific java changes to specific classes,
only relevant to developers. Most users do not care about them either. We still
put them in changes.txt right?
bq. Wouldn't they just be diffing the .proto files between versions to see what
new fields are added, etc?
If I am building some thing based on proto, I may not diff or worry about
looking at the change unless it is flagged as incompatible. Why would you diff
.proto from release to release?
bq. Maybe we need separate tags instead of just one "incompatible change"
checkbox? I've always understood the purpose of this checkbox to alert users
and operators who are upgrading between versions of things they need to be
aware of that can break their applications.
I think the current box serves the purpose. Like I said, it draws people's
attention to such changes. The users can then make a decision for themselves
whether it affects them or not, and how it affects them, instead of we making
that decision for them.
> GetDelegationTokenResponseProto does not handle null token
> ----------------------------------------------------------
>
> Key: HDFS-4362
> URL: https://issues.apache.org/jira/browse/HDFS-4362
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.0.2-alpha
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Priority: Critical
> Fix For: 2.0.3-alpha
>
> Attachments: HDFS-4362.patch
>
>
> While working on HADOOP-9173, I notice that the
> GetDelegationTokenResponseProto declares the token field as required. However
> return of null token is to be expected both as defined in
> FileSystem#getDelegationToken() and also based on HDFS implementation. This
> jira intends to make the field as optional.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
