On 11/6/14 8:44 AM, Greg Stein wrote:
> That is no "decision" because it didn't occur here on the list.
It certainly was discussed on this list:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201306.mbox/%3C51B9C8AB.9090203%40collab.net%3E
A number of us have been operating under the assumption that the voting for
branch integration was adopted. Reasons for doing that were explained in the
above post by C-Mike. However, if it was adopted or not is far from clear in
that thread.
That said, given the ambiguity of our policy situation here I'm not inclined to
try and "fix" any sort of failure on our part to follow such a policy now.
Ironically, this policy is now working counter to the intent. The intent was
to try to keep problematic code off trunk until it was ready. To avoid a
scenario like the move tracking issues we ran into leading into 1.8.0. Now
we've got issues with fsfs7, that at least to me seem to be more procedural
than technical.
IMNSHO I'd much rather have technical issues than be tied up in procedural
limbo. Which is precisely where we are right now with 1.9.
> As Branko notes, "voting" is not typically done in this community. There have
> been only a few in its near-15 year history. I see no reason to change that now.
>
> For features in our codebase, they stay unless/until somebody vetoes that
> feature for some reason. Then it is incumbent upon the person who issued the
> veto, to work with the community to *resolve* that veto. That is *forward* by
> fixing things to address the reason for the veto.
>
> We use consensus rather than voting, so that we operate as a group rather than
> vote-winners and vote-losers. If there is an actual problem that somebody
> finds, then we operate as a group to resolve those problems.
>
> The code is in trunk. It stays, subject to a veto.
>
> No vote is necessary, nor should one be called for.
+1, if there's technical issues let's work through them. But that's what I've
been saying since June.
Received on 2014-11-06 21:07:48 CET