[
https://issues.apache.org/jira/browse/HADOOP-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933931#action_12933931
]
Chris Douglas commented on HADOOP-6685:
---------------------------------------
bq. I had hoped that not threatening a veto but rather providing strong
criticism would elicit compromise and collaboration. It seems to have
unfortunately achieved the opposite. I am sorry to learn that this strategy has
failed and, yes, I am now leaning towards a veto of this issue.
What would a compromise solution look like? You've asserted that you preferred
the previous, stringly-typed solution, which is known. But your comments, so
far, have not been actionable. You wrote a missive on the virtues of Avro and
standard file formats. When Tom brought it up, you objected to packaging. Your
only consistent theme has been the scope of the patch, where you vacillate
between (0) splitting up work that sprawls across too many domains and (1)
importing large, related issues (project direction, redesigning
{{Configuration}}, etc.). Owen has responded to all of these respectfully, by
fully outlining his reasoning, but cannot respond in code because most of your
objections are too general or diffuse to implement. That is, without adopting
the patches you prefer _instead_ of these.
Short of adopting your solution- which was vetoed as unacceptable not only by
Owen, but by others- where are you open to compromise? If the diff were spread
around different issues, would you restrict your veto to a subset of them?
Which of your objections do you consider important enough to block the progress
you grudgingly agreed to months/days ago?
I'm +1 on the patch as-is (with the minor caveat that the leftover imports in
{{Text}} should be omitted). I like the direction, the type safety, and its
independence of {{Configuration}}. The way things are configured in Hadoop
today is horrific. I think we can do better and the progress made here should
be committed.
> Change the generic serialization framework API to use serialization-specific
> bytes instead of Map<String,String> for configuration
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-6685
> URL: https://issues.apache.org/jira/browse/HADOOP-6685
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Owen O'Malley
> Assignee: Owen O'Malley
> Fix For: 0.22.0
>
> Attachments: libthrift.jar, serial.patch, serial4.patch,
> serial6.patch, serial7.patch, SerializationAtSummit.pdf
>
>
> Currently, the generic serialization framework uses Map<String,String> for
> the serialization specific configuration. Since this data is really internal
> to the specific serialization, I think we should change it to be an opaque
> binary blob. This will simplify the interface for defining specific
> serializations for different contexts (MAPREDUCE-1462). It will also move us
> toward having serialized objects for Mappers, Reducers, etc (MAPREDUCE-1183).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
