hadoop-general mailing list archives

On May 4, 2011, at 11:52 PM, Jean-Daniel Cryans wrote:
> Roy,
>
> On Wed, May 4, 2011 at 7:22 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>> The ASF is a vehicle for whomever wishes to collaborate on a
>> given project. Collaboration means helping do the work. Those
>> who do the work may do so for whatever reasons that they think
>> are good, whether it is because they feel like being charitable
>> today, they get paid a salary and the big boss said "work on
>> this part", or because they just have an itch worth scratching.
>>
>> Apache does not care why people choose to collaborate or
>> how they choose to apply their own intellectual efforts. We
>> welcome all forms of contribution under the terms of our license.
>
> I don't think I was arguing against the contribution of the code in
> that branch, it's very welcome, but I'm questioning (and ranting
> about) the motivation for releasing a version that even just by name
> is a weird hulla-hoop around the usual development practices that
> Hadoop has had in the past (not that it's set in stone).
Yes, and I said that kind of questioning is not appropriate.
You are not responsible for other peoples' motivation.
> So I wanted to contribute my negative non-binding vote to highlight
> that this release is probably very confusing for the general user.
> This is 0.20, but it's not. Also it has more numbers, and it starts at
> 203. Why doing this at all instead of just moving on with 0.22? Or is
> 0.22 bound to be like 0.21? It almost begs the question if this should
> be called 0.22.0 then.
Yes, I already made that same point. You don't need to talk about
motivation in order to do so.
If I had a vote, I would have voted -1 just because version numbers
do matter to users, the three number form is well-known, and minting
new versions is far cheaper than adding extra numbers. I'd have cut
the release candidate as 0.30. However, I did not do that work.
The person who did the work chose 0.20.203.0. Anyone who doesn't
like that should vote accordingly and, preferably, make your
communication about such things more open in the future so
that you don't waste others' time on extra builds. And if the
majority thinks releasing these bits are more important than my
concerns, then I have to accept that as the will of the project.
Please note also that policies are not technical discussions.
Likewise, version numbers are not technical. If those were
technical changes then anyone on the PMC could veto them,
which would effectively mean anyone could veto a release
and the project would quickly devolve into tyranny by minority.
Likewise, just because I said that a successful release defines
its own set of precedents (and therein policy), that doesn't
mean the project can't vote on a new policy the next day or
make another release that sets it again moving forward.
Progress is in the doing.
....Roy