On Thu, May 2, 2013 at 2:11 AM, Konstantin Shvachko <shv.had...@gmail.com> wrote: > On Thu, May 2, 2013 at 12:07 AM, Chris Douglas <cdoug...@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
