On Thu, Nov 6, 2014 at 2:07 PM, Ben Reser <ben_at_reser.org> wrote:
> 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.
>
Yeah :-/
>
> 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.
>
I haven't been able to pay enough attention to Subversion over the past
months :-( ... what is this "procedural limbo"?
In my mind, we have code. Start the release process. If it gets (3) +1
votes for release, then it goes out the door. Pretty simple. Is it just
that some people don't want Feature A in that release? They better find a
good/technical reason to veto, then. And that will only pause it, until the
problem is resolved.
If people think Feature A hasn't had enough testing, then they should do
the testing to show they are right. "serf as default" languished for years
because of naysayers. Philip did some great work to demonstrate specific
problems, and so we kept serf as optional. When those all got fixed, we
flipped the bit.
Forward progress is the goal. To *hold back* change, then you must veto.
It sounds like Feature A may have been due to a large branch merge. I don't
know that history (but it sounds like I need to go research it). There are
ways to best handle that (especially if it becomes a repeated pattern), but
I'm guessing we're past that now.
>...
> > 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.
>
Thanks,
-g
Received on 2014-11-07 01:02:27 CET