Greg Hudson <ghudson@MIT.EDU> writes:
> So, I'm feeling like ra_svn is being treated as a second-class citizen
> by some developers. Before and during its development, I was assured
> that it would be well-received as a pre-1.0 feature, but now people seem
> to feel free to check in stuff which is known to leave ra_svn broken or
> which implements features in the other ra layers but not in ra_svn.
>
> Without a lot of effort from me (which can't happen; I have to put too
> much effort into my job right now), this will be a self-reinforcing
> attitude. ra_svn will be the access layer which doesn't require Apache
> but also doesn't work so well.
>
> I am not pleased.
There are several points here; I'll try to address them individually.
First of all, I'm sorry -- the breakage in this case is my fault, and
of course I'll fix it. I didn't know the changes would break ra_svn
when I checked them in. Not sure what makes you claim the stuff was
"known to leave ra_svn broken". Maybe it was known to someone, but
not me :-).
The more general issue is harder to solve. Our test suite takes (on
my development box) about a half-hour to run over any given RA layer.
That means that each RA layer we add adds a half-hour of testing time.
I can run the tests over ra_svn more often, but that will mean
sometimes *not* running them over dav, or local. More likely, I'll
run some subset of the tests over each of the ra layers, as a sanity
check (I should really have started doing that earlier). It's not
ideal, but an 1.5 hour test run for every change is not sustainable.
Development would slow down too much.
Although I can understand why you're frustrated, your characterization
of the situation is frankly unfair:
> I was assured
> that it would be well-received as a pre-1.0 feature, but now people seem
> to feel free to check in stuff which is known to leave ra_svn broken or
> which implements features in the other ra layers but not in ra_svn.
Yes, and the assurances are still true, temporary breakage
notwithstanding. However, you can't just drop in a new RA layer, and
then largely step away from its development and maintenance for N
weeks, without seeing some negative side effects. There's going to be
some lag while others learn how to pick up the slack.
I mean, what did you expect, Greg?
Adding a new RA layer means there's another maintenance path in the
project, whenever someone implements a new feature (say, checksums)
that affects the RA layers. You are under no obligation to maintain
it, but what are others supposed to do? The checksums issue was filed
long before ra_svn existed; should the addition of the new layer
suddenly magnify the work needed to resolve that issue? Should
schedules suddenly be increased by .5 because of of the new code?
You have a complaint, but you don't offer a solution (except for me to
spend more time in front of a computer than I already do, thanks very
much). Well, I agree with your complaint, and I don't have a solution
either. So this situation looks symmetrical to me; the only
difference is I didn't mail the list about my displeasure.
It would be nice if resources were infinite. As you know, they're
not. You don't have to help ra_svn keep abreast of interface changes,
even though you're the most qualified person to do so. But don't
complain because we can't always keep up. I spend enough hours in
front of a computer editing Subversion code as it is; I don't need to
be told I'm obligated to maintain a whole new library even for issues
that were filed & estimated before that library existed -- nor do the
other volunteers.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 2 00:05:29 2003