hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Owen O'Malley" <omal...@apache.org>
Subject Re: [VOTE] Direction for Hadoop development
Date Tue, 30 Nov 2010 00:22:09 GMT
On Mon, Nov 29, 2010 at 3:14 PM, Doug Cutting <cutting@apache.org> wrote:

We don't vote on a project direction statement.  Rather folks present plans,
> others may present their conflicting concerns, and we need to get these to
> meet in order to make progress on a particular issue.
>

We haven't in the past, but clearly there is currently disagreement on the
direction for Hadoop that is blocking forward progress. Using a vote to
decide on project direction is far better than vetoing patches based on
disjoint visions of how to move forward. If the project votes for a
direction, a veto that is based on an opposing direction is clearly invalid.

I too support continuing support for SequenceFile.
>

I said far more than that. I said that it should be actively maintained as
the framework evolves. Clearly the generic serialization changes are far
more useful if they include a file format that uses them. Extending
SequenceFile and TFile is a good thing.

I do not support extending SequenceFile's format in substantial ways.  A
> proliferation of expressively equivalent yet incompatible file formats
> hinders the interoperable evolution of the Hadoop ecosystem.
>

There is no equivalent functionality and even if there was, it would still
be worthwhile extending SequenceFile since they are so heavily used. Making
SequenceFile support the new serialization API increases their value with
minimal disruption to users.

I do not support adding new dependencies to the classpath of MapReduce user
> tasks.


That isn't reasonable. As Hadoop evolves, we have and will continue to add
dependences. For example, in your last MapReduce (MAPREDUCE-980) patch you
added avro and paranamer as dependences.

-- Owen

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message