hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: Heads up - 2.0.5-beta
Date Fri, 03 May 2013 00:53:03 GMT
On Thu, May 2, 2013 at 2:11 AM, Konstantin Shvachko
<shv.hadoop@gmail.com> wrote:
> On Thu, May 2, 2013 at 12:07 AM, Chris Douglas <cdouglas@apache.org> wrote:
>> Can anyone remember why we vote on release plans? -C
> To vote on features to include in the release.

Since most features are developed in branches (requiring a merge
vote), each change is RTC, and the release itself requires a vote... a
vote on the executive summary for a release is a poor time to engage
development. It doesn't seem to accomplish anything when it's not a
formality, so maybe we're better without it. Thoughts?

> I am arguing against invasive and destructive features proposed for the
> release.

Heh; do we need new tags in JIRA?

Setting aside the choice of words, we don't assign work by voting.
Stability is a shared goal, but conflating it with inertia after our
experiences with the 0.20 forks, 0.21, and 0.22 takes exactly the
wrong lessons from those episodes.

If you want to create a 2.x branch, pull out the features you view as
high-risk, and invite others to join your effort: you don't need
anyone's permission. If the bylaws contradict this, then that's a bug.
But one can't vote a set of priorities into preeminence, he can only
convince others to share them *and work on them.* It's cheap to
reassign versions to accommodate whatever shape the community takes,
but voting first and expecting everyone to follow the result has never
worked. Cos's chart gives the lie to the attempt: every time we've
tried, we end up reassigning the versions according to reality,
anyway. -C

View raw message