[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [VOTE]: Default http-client for 1.7 Serf or Neon

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 5 Aug 2011 05:34:53 -0400

On Fri, Aug 5, 2011 at 02:46, Branko Čibej <brane_at_xbc.nu> wrote:
> On 05.08.2011 06:26, Greg Stein wrote:
>> On Aug 4, 2011 11:43 PM, "Branko Čibej" <brane_at_e-reka.si
>> <mailto:brane_at_e-reka.si>> wrote:
>> >...
>> > Speaking of politicking, I don't see any technical explanation for
>> > Greg's veto in the 1.7.x STATUS, which causes me to wonder why anyone is
>> > treating it as valid in the first place.
>> The change goes against our previously-stated direction. Using Neon
>> holds us back from future improvements (discussed across many
>> threads), so I consider such a change a regression in our codebase.
> All of the above falls under the heading of hand-waving.
>> There are no registered and actionable bugs.
> You have a point there. It's up to the people who talk about real-world
> problems with serf to actually submit bugs. Of course, given the nature
> of the bugs, they'll most likely be close to impossible to reproduce.
>> We made serf the default shortly after 1.6.x was branched. It has been
>> the default for two+ years.
> During which time close to zero real-world users actually used serf.
>> Changing the default does not help in our project's intended
>> direction, nor indication that we would avoid this same discussion
>> next time around. This is the time to move forward, as we have done
>> with so many other moving parts of this project.
> None of the changes to date were so potentially destructive to existing
> installations. Note the "potentially" -- it's up to the people who are
> vocal against ra_serf to provide the real-life examples, since otherwise
> this whole discussion is nothing but hot air and we might as well toss a
> coin and get the same information content.

Right. That pretty much summarizes my feeling. I don't want to respond
in-line since you summarize it well: without real-life examples, we
have nothing to work against here.

Our Neon code was debugged back in the day. Our future no longer rests
with that codebase. We need to accept that some number of bugs will be
reported based on the code we have changed. We know how to produce
bugfixes, and how to produce updated releases. We know that bugs in
serf (along with ra_serf) will get fixed. There is no blockage to
helping our users.

We have changed a LOT of code, across the entire product. We have
added a LOT of code. We are moving forward.

We recognize that issues will arise, and we are ready to step up and
resolve them.

Yet... we have seen bugs crop up over the past week in a number of
other areas (merge? mod_dav_svn? log? fs txns?). We accept those as
normal. They're fixed and backported. This is how we should be
operating on ra_serf, too. There is nothing special about it.

Received on 2011-08-05 11:35:41 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.