Erik Huelsmann wrote:
>>>>i.e. "Subversion supports the following platforms Windows 2K, XP,
>>>>solaris xxx, RedHat Linux > x.x, Debian > x.x. Also required are
>>>>Apache > x.x, etc."
>>>We don't enumerate all Linux distros, but in the README there is a list
>>>libxml / expat
>>This is good. I think you should also list version numbers and stick to
>>them. That way users would have more confidence that they won't have to
>>replace their OS just to upgrade subversion. Today I've seen RedHat 9.0
>>described as EOL. It's less than 2 years old! Granted, I primarily
>>blame RedHat itself for this state of affairs. But still, what features
>>above what the current version of these packages support does Subversion
>>need? Being conservative in what features you'll be using from
>>dependency packages will increase subversion's stability and require
>>less of a bleeding-edge mentality.
> Some of the dependencies listed are dependencies of dependencies: Apache and
> Neon can build against libz, Neon builds against libxml or expat. We can't
> really make any promises about which version will be the minimum for any
> period time for the deps of deps.
> Also, since we built on non-1.0 software (or at least development software
> as in case of SWIG 1.3), we can't guarantee we won't require a new version
> next 1.x release: for example Neon will have some crucial fixes in its 0.25
> release we need to provide better user experience [interruptable checkouts].
>>>Having a list of minimum requirements by itself does not assure you of
>>>Only the intention to keep them stable will help you there.
>>Agreed. That's what I'm asking for.
> I'm sorry, but we do the best we can. We can't guarantee it. After all, you
> want next releases to get better for you too.
>>You haven't answered my question. If you can't say, we'll work with any
>>apache back to v. x.x.x and plan to keep it that way, you do not enhance
>>your reputation for stability.
> Well, I think the example was poorly chosen: of any webserver you can run, I
> think Apache is the most stable one available (depending on which modules
> you load ofcourse).
> Apart from that: we try to keep ourselves to patch releases. In case of SWIG
> 1.3, that does not help as even patch releases are just not compatible. In
> case of Neon, a new feature will have major usability consequences (for the
> better). I think *not* adopting such new versions costs us users too.
> BTW: Software stability and keeping up with newest version releases might
> not be conflicting. Adopting new code of our own too soon and carelessly is
> going to have
> much more impact.
>>>Have a look at the testimonials page to see who's using svn:
>>I'm sure they are. But simpler installs are a big part of "ready for
>>prime time." At this point in time, I would not dream of recommending
>>that my employer adopt subversion. It demands a higher caliber of
>>developer than those I've seen there. Without a GUI, many of them are
>>lost. I hope to be able to recommend subversion there once there is a
>>stable subeclipse. You guys are making progress. Keep it up and you'll
> Well, in my opinion, 'simple installs' should use pre-built binaries. As
> soon as you have to build yourself (for whatever reason), you just aren't a
> simple install anymore. I'm sorry the summersoft rpms did not work out,
> since that obviously is a BFI (Bad First Impression). I'm affraid it doesn't
> mean anything about the Subversion software though.
For whatever reason? I was happy enough with the prebuilt binaries
(they only took me one whole weekend to load). But if I wanted to use
subclipse I had to have javahl (too slow otherwise). And if I wanted to
have javahl I had to build from source. And that led to a bunch more fun.
Perhaps the subversion team needs to clarify what its "support" for
RedHat 9 and earlier means. Perhaps you need to say going forward that
users of these systems are pretty much on their own after subversion
1.x.y (whatever x and y are). I wouldn't blame you for this. I'm
pissed at RedHat for dropping support for a distro less than a year old.
(Then again, I didn't PAY for it, so who am I to complain - but it is
an unwelcome change from a pattern that I was previously used to from them).
I can understand why subversion is not ready yet to put a line in the
sand and say what its minimum configuration going forward is going to
be. But there is a price you pay for this, and no, it's not all your
fault, and maybe it's not too high.
When you say it doesn't mean anything about the Subversion software
though, I disagree. Subversion is the whole package, not just its core.
As difficult as that may be for you to accept, I think you need to
accept it. You will be judged by it, just as CVS is judged by its
I'm still willing to help you guys as much as I can, with my postings of
whatever educational value my various missteps may have, but you're in a
difficult place. You're placed yourself in a market developing software
with developers as your end users. We're one tough crowd. As long as
your product requires users to make OS-level changes, it won't be easy
Anyway, I have the whole package up and running now. It took me two
weeks. But I did it.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Feb 16 03:08:20 2005