[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: Branko Čibej <brane_at_xbc.nu>
Date: Fri, 05 Aug 2011 08:46:19 +0200

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.

-- Brane
Received on 2011-08-05 08:47:50 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.