On Aug 4, 2011, at 1:50 PM, C. Michael Pilato wrote:
> On 08/04/2011 03:36 PM, Greg Stein wrote:
>> On Thu, Aug 4, 2011 at 15:20, Mark Phippard <markphip_at_gmail.com> wrote:
>>> ...
>>> vote for their preference. I am not saying that the simple majority
>>> decision of this vote should become the default.
>>
>> Not until I'm convinced to remove my veto. We've discussed several
>> times that the future direction lies with serf, and I believe it is a
>> wrong choice to move us away from that. The issue tracker has not had
>> any serf-related bugs for a while, so there is nothing to indicate
>> "not ready".
>
> Greg,
>
> It's obvious that you firmly believe that the future lies with Serf. And
> I'm aligned with you there (though with some caveats you'd likely disagree
> with). But nobody is asking about that future -- we're asking about the
> present. We're talking about taking what many believe to be a step backward
> in terms of the relative stability of Subversion as a whole for questionable
> (if any) gain. Sure, Serf's stability will improve the more it's used *and
> its bugs are reported* -- no question about it. I'm just not convinced that
> users will take the time to report an issue against Serf when an immediate
> workaround for pretty much any of their Serf-specific problems already
> exists ("I'll just switch to Neon"). Further working against this is the
> fact that our single most common binary package producer, TortoiseSVN, plus
> others are saying that for the sake of their user base, they'll switch to
> Neon by default anyway. Who then, will be using Serf and reporting to us
> its specific problems?
>
> I'm concerned about our effectively transmitting this message from the
> Subversion developers to its users: We've made the decision to
> intentionally offer you, by default, a product that is known to be less
> stable than it could be in exchange for ... nothing, really, except the
> benefit that *we* get (and then you'll get, by extension, some time in the
> future) by forcing you to be our QA department. That doesn't strike me as
> the embodiment of "community before code".
>
> All that said, if your veto hinges on the presence/absence of
> 1.7.0-milestoned bugs filed against Serf alone, that does seem fair to me.
> After all, it's practically impossible to "fix" what cannot be clearly (and
> reliably) demonstrated as broken.
On the veto issue, it's odd that Greg is veto a revert of a commit change that originally occurred on trunk and is now sitting on the branch. It does seem odd one can veto the move back to the original default implementation.
Just wondering, couldn't we veto the commit that made serf the default?
Blair
Received on 2011-08-05 03:48:20 CEST