On Mon, Nov 29, 2010 at 3:14 PM, Doug Cutting <[email protected]> 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
