You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by sc...@javactivity.org on 2005/02/11 19:19:42 UTC
Roles within subversion development
I had hoped my "Victory" thread would have sparked more discussion on
the subject of whether the suite of tests was an appropiate default
inclusion in source RPMs, and the difficulty involved in building
Subversion. I'm a new member of your community - so for all I know
you've discussed this to death already.
However, the discussion seems to have settled on whether I should or
should not have attempted to build the source RPM as root (my position
is now that I should not have, but that I had been building source RPMs
that way for years - and that a week's worth of hair-pulling was too
great a penalty to pay for this oversight - that the RUNNING of apache
within the build process makes Subversion a rather unusual beast and
that some method for warning the builder might be appropriate).
More interesting to me are these questions:
Is it appropriate to put what are essentially developer unit tests into
a source package such that they are run by default? Or should the user
of such a package be entitled to assume that it would not have been
released if all such tests had not already passed (assuming a properly
set up environment - which can be tested within the source rpm). At
most, I would think, these tests are relevant to the packager of such
RPMs.
I think we may have a confusion here between environment-checking tests
and developer unit tests, and that we are trying to make one set of
tests developed for the second purpose also serve the first. And this
DOES have consequences - it drives users away from using wanting to use
Subversion. Or it leads to loose talk such as "RH 9.0 is not supported
by subversion".
Speaking of which, another related point is this: Has the Subversion
development team targeted a minimum set of system requirements?
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." It still seems a little strange to me that I had
to upgrade my RH9 system with various patches developed for Fedora,
etc. Finalizing a set of minimum requirements for the foreseeable
future would reassure me that I will not have to go through such
trouble with the next subversion release.
In the Jakarta-commons-net project where I am a committer we only
recently dropped support for Java JDK 1.1. (And we only bumped the
minimum level to 1.2). We very deliberately forced ourselves to write
code that was now suboptimal to preserve the contract we had with our
users. Does subversion have such a contract? I think if it did, it
would put to rest some of this "ready for prime time" controversy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roles within subversion development
Posted by Julian Foad <ju...@btopenworld.com>.
Steve Cohen wrote:
>>[...] 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.
Erik Huelsmann wrote:
> 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.
I don't think that is right. For example, if we require Apache >= 2.0.49, and
Apache 2.0.49 requires libz >= 99, then the minimum version of libz that we
require is 99. If a user has a later version of Apache that needs a later
version of libz then obviously they will have a later version of libz, but we
didn't require that.
Actually we shouldn't try to specify deps of deps authoritatively; we should
just say something like, "For your convenience, here are what we believe to be
the minimum dependencies of some of the packages we depend on: ..."
> 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].
This seems to miss Steve's point that we don't always _need_ to provide such
enhancements. In this example, we could provide interruptable checkouts iff
the installed version of Neon supports it, and _recommend_ such a version of
Neon in order to provide a better user experience, but not _require_ it.
Of course that is more work for us, so we have to decide for each such case
whether it is worth the effort, but it's a valid argument that we should
consider keeping our requirements low in order to make installation easier.
This applies more and more as the project matures and the number of users
increases.
[...]
> 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.
That depends on whether the use of the new version is mandatory or optional.
Maybe our dependencies are already conservative enough for most people - I
don't know. Certainly we need to keep this in mind.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roles within subversion development
Posted by Steve Cohen <sc...@javactivity.org>.
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
>>
>>of
>>
>>>all prerequisites:
>>>
>>>Apache
>>>APR
>>>Neon
>>>Berkely DB
>>>libxml / expat
>>>libz
>>>gettext
>>>etc.
>>>
>>>
>>
>>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
>>
>>that.
>>
>>>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:
>>>http://subversion.tigris.org/propaganda.html
>>
>>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
>>get there.
>
>
> 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.
>
>
> bye,
>
>
> Erik.
>
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
Eclipse support.
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
for you.
Anyway, I have the whole package up and running now. It took me two
weeks. But I did it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roles within subversion development
Posted by Erik Huelsmann <e....@gmx.net>.
> >>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
> of
> > all prerequisites:
> >
> > Apache
> > APR
> > Neon
> > Berkely DB
> > libxml / expat
> > libz
> > gettext
> > etc.
> >
> >
>
> 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
> that.
> > 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:
> > http://subversion.tigris.org/propaganda.html
>
> 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
> get there.
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.
bye,
Erik.
--
DSL Komplett von GMX +++ Superg�nstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roles within subversion development
Posted by Steve Cohen <sc...@javactivity.org>.
Erik Huelsmann wrote:
> Hi Steve,
> In this strategy the unit tests are used to determine whether consecutive
> revisions still provide the functionality we set out to deliver. However
> build processes are not guaranteed to be without problems: we've seen builds
> linked against two different bdb versions at the same time, builds which
> were linked against one version but running against another, etc. These
> problems can be detected by the unit tests too. One should just not assume
> that because the build completed successfully that you were provided with a
> correctly working toolset.
Yes, I concede your point. My personal use of a subversion repository
is not the case you're testing for. My "repository" is really just a
toy, a learning experience. If I was supporting a large development
team with a large investment in the code, I'm sure I would have felt
differently. I won't complain about the fact of unit tests again.
You've convinced me on that point.
> Not really. The unit tests provide you with a good estimate of the health of
> your build and are run post-build. Configure tests (which we have too) serve
> to identify the environment pre-build.
This is what I missed. Maybe I was made a little crazy from watching
two hours of build go by (on more than one occasion) only to fail, not
because there was anything wrong with my build of subversion but because
apache wouldn't start! Had this been caught earlier in the process, I
wouldn't have complained. Perhaps reorganzing the test suite to run the
precondition tests before the unit tests would be one way to minimize this.
>
>>And this
>>DOES have consequences - it drives users away from using wanting to use
>>Subversion.
>
> Well, I don't see it that way: I think it is a testimonial to the
care the
> team takes to provide you with a toolset which wont corrupt your work.
There is resistence from some quarters to switching to subversion and I
think you're somewhat in denial if you that think incidents like this
have nothing to do with it. But don't shoot me, okay. I'm a messenger.
I'm the guy persisting with subversion in spite of this. I'm one who
voted to go forward in spite of misgivings.
> We have binaries for most platforms (including RH9). That should serve most
> people not wanting/able to build themselves.
Unless they want to use subeclipse with javaHL. That is what drove me
down this path.
>
>
>>Or it leads to loose talk such as "RH 9.0 is not supported
>>by subversion".
>
>
> Even if we provide binaries for exactly that platform?
>
I've heard it from more than one helpful soul during this ordeal that I
should upgrade to RHEL, Fedora, CentOS, whatever. There's a lot of
misinformation out there.
>
>>Speaking of which, another related point is this: Has the Subversion
>>development team targeted a minimum set of system requirements?
>
>
> No. There are so many different uses for Subversion that there's hardly a
> good estimate. There were people building it into embedded systems where
> both space and computing power are limited. Others version the company
> assets and provide svn with a quad opteron and 1TB disc...
>
>
>>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 of
> all prerequisites:
>
> Apache
> APR
> Neon
> Berkely DB
> libxml / expat
> libz
> gettext
> etc.
>
>
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.
>>It still seems a little strange to me that I had
>>to upgrade my RH9 system with various patches developed for Fedora,
>>etc.
>
>
> So what was wrong with the binaries you can download from the summersoft
> site?
But these ARE from Fedora, not RH9. My Apache "main page" (obtained
from this site) now claims it's running on Fedora. And the
documentation wasn't quite right. It recommended --nodeps installs, one
of which knocked out my apache server. Eventually, though, I did get it
working but not the way the site said to. But then I had to get into
source building in order to get javaHL for subeclipse.
>
>>Finalizing a set of minimum requirements for the foreseeable
>>future would reassure me that I will not have to go through such
>>trouble with the next subversion release.
>
>
> Having a list of minimum requirements by itself does not assure you of that.
> Only the intention to keep them stable will help you there.
Agreed. That's what I'm asking for.
>
>
>>In the Jakarta-commons-net project where I am a committer we only
>>recently dropped support for Java JDK 1.1. (And we only bumped the
>>minimum level to 1.2). We very deliberately forced ourselves to write
>>code that was now suboptimal to preserve the contract we had with our
>>users. Does subversion have such a contract? I think if it did, it
>>would put to rest some of this "ready for prime time" controversy.
>
> Do we have a 'ready for prime time' controversy? People have been versioning
> multi-GB datasets from years before svn went 1.0 without many problems.
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.
> Have a look at the testimonials page to see who's using svn:
> http://subversion.tigris.org/propaganda.html
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
get there.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roles within subversion development
Posted by Erik Huelsmann <e....@gmx.net>.
Hi Steve,
> I had hoped my "Victory" thread would have sparked more discussion on
> the subject of whether the suite of tests was an appropiate default
> inclusion in source RPMs, and the difficulty involved in building
> Subversion. I'm a new member of your community - so for all I know
> you've discussed this to death already.
Welcome. As you probably have found by now, we're trying to work by very
high standards. In order to keep standards as high as they have been until
now, we want to understand exactly what it is that drives enhancement
requests, bugreports etc. It looks like we don't care and give you a hard
time, while actually you should start worrying when no reactions come to
your mails.
> However, the discussion seems to have settled on whether I should or
> should not have attempted to build the source RPM as root (my position
> is now that I should not have, but that I had been building source RPMs
> that way for years - and that a week's worth of hair-pulling was too
> great a penalty to pay for this oversight - that the RUNNING of apache
> within the build process makes Subversion a rather unusual beast and
> that some method for warning the builder might be appropriate).
The subversion team, including its packagers take the utmost care to provide
you with software that does what it is advertised to do. In the case of
Subversion this might be more appropriate than a gettext or bash build: some
people will store their complete 20 years software development history in
it. Any failure will be fatal then.
In this strategy the unit tests are used to determine whether consecutive
revisions still provide the functionality we set out to deliver. However
build processes are not guaranteed to be without problems: we've seen builds
linked against two different bdb versions at the same time, builds which
were linked against one version but running against another, etc. These
problems can be detected by the unit tests too. One should just not assume
that because the build completed successfully that you were provided with a
correctly working toolset.
> More interesting to me are these questions:
> Is it appropriate to put what are essentially developer unit tests into
> a source package such that they are run by default? Or should the user
> of such a package be entitled to assume that it would not have been
> released if all such tests had not already passed (assuming a properly
> set up environment - which can be tested within the source rpm). At
> most, I would think, these tests are relevant to the packager of such
> RPMs.
Sure. If the unit tests did not pass on our systems there would not have
been a release, but if it works on my system, that does not guarantee it
works on yours.
> I think we may have a confusion here between environment-checking tests
> and developer unit tests, and that we are trying to make one set of
> tests developed for the second purpose also serve the first.
Not really. The unit tests provide you with a good estimate of the health of
your build and are run post-build. Configure tests (which we have too) serve
to identify the environment pre-build.
> And this
> DOES have consequences - it drives users away from using wanting to use
> Subversion.
Well, I don't see it that way: I think it is a testimonial to the care the
team takes to provide you with a toolset which wont corrupt your work.
We have binaries for most platforms (including RH9). That should serve most
people not wanting/able to build themselves.
> Or it leads to loose talk such as "RH 9.0 is not supported
> by subversion".
Even if we provide binaries for exactly that platform?
> Speaking of which, another related point is this: Has the Subversion
> development team targeted a minimum set of system requirements?
No. There are so many different uses for Subversion that there's hardly a
good estimate. There were people building it into embedded systems where
both space and computing power are limited. Others version the company
assets and provide svn with a quad opteron and 1TB disc...
> 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 of
all prerequisites:
Apache
APR
Neon
Berkely DB
libxml / expat
libz
gettext
etc.
> It still seems a little strange to me that I had
> to upgrade my RH9 system with various patches developed for Fedora,
> etc.
So what was wrong with the binaries you can download from the summersoft
site?
> Finalizing a set of minimum requirements for the foreseeable
> future would reassure me that I will not have to go through such
> trouble with the next subversion release.
Having a list of minimum requirements by itself does not assure you of that.
Only the intention to keep them stable will help you there.
> In the Jakarta-commons-net project where I am a committer we only
> recently dropped support for Java JDK 1.1. (And we only bumped the
> minimum level to 1.2). We very deliberately forced ourselves to write
> code that was now suboptimal to preserve the contract we had with our
> users. Does subversion have such a contract? I think if it did, it
> would put to rest some of this "ready for prime time" controversy.
Do we have a 'ready for prime time' controversy? People have been versioning
multi-GB datasets from years before svn went 1.0 without many problems. Have
a look at the testimonials page to see who's using svn:
http://subversion.tigris.org/propaganda.html
bye,
Erik.
--
DSL Komplett von GMX +++ Superg�nstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org