----- Original Message ----
> From: Mark Mielke <mark_at_mark.mielke.cc>
> To: Joe Schaefer <joe_schaefer_at_yahoo.com>
> Cc: Karl Fogel <kfogel_at_red-bean.com>; Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>; Mark Phippard <markphip_at_gmail.com>; Subversion Dev <dev_at_subversion.apache.org>
> Sent: Sun, January 17, 2010 12:59:24 PM
> Subject: Re: Subversion in 2010
>
> >
> >
> > Karl said that "more bugs = more users = probably good". I challenged this. If
> you think I am wrong for challenging this, state your case.
>
> Another point on this I forgot to mention:
That doesn't change my opinion that this is an irrelevant question for a
healthy open source project to concern itself with.
> With every conclusion, there should be some behaviour to model. That is, if we
> conclude that more bugs equates to more users, and this is healthy, what is the
> conclusion? Is the conclusion that we should accept a growing list of bugs as
> inevitable? What is the value of this conclusion? How are customers/users being
> better served by this conclusion?
>
> Is the conclusion that bugs should be left as is treated as lower priority
> compared to new features, allowing developers to work on new features? At what
> point does this become foolish to the point that customers/users abandon the
> product as being bug-ridden and architectually unsound?
>
> What makes this relevant to this mailing list, is that this is where Subversion
> is today. It had a head start on other products, but it is falling behind these
> other projects. Beyond a certain threshold, people will ditch their investment
> in a product if another product available does what they want.
>
> This isn't guilt. This is just practical reality. Joe: You stated your own
> dis-satisfaction with various aspects of the Subversion architecture. Other
> solutions do not have these particular problems. What keeps you on the
> Subversion ship, and how long would you be willing to accept your complaints
> remaining unaddressed?
Well there was no competition in 2003? when the ASF adopted Subversion as it
was clearly better than CVS. In 2010 there is a significant DVCS market now,
and some of those products have compelling features that a centralized version
control system like subversion will likely never be able to acquire (and vice
versa, but having a discussion of the relative trade-offs is something Apache
members *love* to argue about internally).
Switching to git or mercurial or whatever would entail a significant organizational
cost as our smallish set of svn repositories house all our essential documents and code.
The ASF isn't really looking to support multiple version control tools as it's not
trying to compete with places like google code or sourceforge, so if we switched we'd
want all projects (except subversion of course) to migrate at some point.
At this point in time however, there is no significant interest amongst Apache
Infrastructure to switch, and those are the folks charged with such decisions.
The subversion team has met our needs adequately (or better!) to this point, and
we expect that relationship to continue to be a healthy one. Even if svn doesn't
support merges on renamed files, or the wc-ng stuff is still not particularly
groundbreaking in 1.7.
Received on 2010-01-17 19:21:39 CET