[
https://issues.apache.org/jira/browse/HDFS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018478#comment-13018478
]
Allen Wittenauer commented on HDFS-1822:
----------------------------------------
To quote you earlier:
bq. Trunk should be the source of truth, ensuring the opcodes are chosen
uniquely across different releases.
Trunk *is* the source of truth. We have a situation where we have a bunch of
forks and an unreleased branch that conflict with trunk. Apache has no
authority over the forks. It does have authority over the branch. Branches
are generally considered to be subserviant to trunk.
Trunk, being the source of truth, provides the definition for these opcodes.
The forks+branches are incorrect, even if they were released first/in more
used/whatever. That's the risks related to forking and those folks got burned.
Any patches made need to happen in the unreleased branches and any forks that
want to follow Apache, not on trunk.
Now, if these opcodes had not already been part of a release (0.21), I think
I'd be more sympathetic to an alleged "bad merge". But these opcodes are out
in the wild in an official Apache branded release. That makes them official.
> Editlog opcodes overlap between 20 security and later releases
> --------------------------------------------------------------
>
> Key: HDFS-1822
> URL: https://issues.apache.org/jira/browse/HDFS-1822
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.21.0, 0.22.0, 0.23.0
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Priority: Blocker
> Fix For: 0.22.0, 0.23.0
>
> Attachments: HDFS-1822.patch
>
>
> Same opcode are used for different operations between 0.20.security, 0.22 and
> 0.23. This results in failure to load editlogs on later release, especially
> during upgrades.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
