On Fri, May 29, 2009 at 09:27:51AM -0400, C. Michael Pilato wrote:
> Folks, we made a pretty serious regression in Subversion 1.5 regarding the
> way our copy and move operations drive the commit editor. The result is
> that operations previously permitted via a particular authz policy no longer
> do. As a result, there are people still running 1.4 simply because they
> can't use 1.5. That's really bad, because 1.4 has dropped from official
> non-emergency support already. This is tracked in issue #3242 [1], and that
> issue is started to heat up.
Yes. For many people using authz, things are really broken.
> I see three courses of action:
>
> * Continue to ignore the issue. This comes with all the disadvantages
> you might assume from such a user-unfriendly approach.
>
> * Rewrite Subversion's authz framework, perhaps in the way I've
> recommended in issue #3380 [2]. This is very non-trivial amount
> of work though, and not backportable to existing release streams.
>
> * Fix the copy and move code to be more conservative in their
> approach. I took a stab at this a while ago, and got completely
> lost in the logic. My guess is that Hyrum is the only person who
> really has the big picture in his head there. But as a stopgap,
> I wonder if we couldn't just resurrect the 1.4 logic (as a sibling
> to the 1.5 stuff), and make the APIs fork immediately: doing a
> single-source copy or move? Use the old logic (plus some merge
> tracking handling). Else, use the new, multi-source-supporting
> stuff.
>
> I'm a bit concerned about our relationship with our user base, and not just
> saying that to be dramatic.
I think the problem is bigger than "just" the relationship to our
user base. Even though that problem alone is a huge one.
And I'm not just saying that to be dramatic ;)
We have a few serious issues that have been lying around unfixed for
too long, and which we ended up releasing with. The effect of this is
both user _and_ developer frustration.
My impression is that last year, we had more active people working
on Subversion than we do have now. Though I haven't really counted the
number of commits per contributor or some such figure. It's just my
personal impression based on who I get to communicate with on the
dev list and on IRC. Some people are simply less active, and the most
likely reason is that they stopped having fun.
Work lies around because people do not have fun tackling really
difficult problems under pressure from users demanding a fix under
a right-now-or-else mantra, like $most_verbose_user_posting_to_#3242.
I think we should really reconsider the way we are doing testing for
releases to prevent such problems. We cannot afford to release with
regressions like this. The consequences are too dire.
We have to catch stuff like this before we release, not after.
The kinds of bugs that get fixed in point-releases should be small,
simple problems. Not design problems like #3242. A broken design
should not be released, it should not pass our testing.
But our current release and testing process cannot possibly capture
all potential problems, and it has little chance of catching the ones
which are really only occurring in huge setups like some of our advanced
users are running.
I mean the likes of users having good reasons for using authz, with
hundreds of developers in their teams relying on Subversion and doing
insanely huge merges every day.
I have some plans to try to fix this in the long term.
More on that at some other time, in a different thread, because
explaining this now would go too much off-topic for #3242.
For those who are interested to know more about this now, take an
hour to watch this talk: http://www.youtube.com/watch?v=i7pkyDUX5uM
You should pretty much be able to infer what my ideas are and
were I got them from :) And I hope we'll be able to bring the fun
back for people who have lost it.
> What do you guys think? Is there anyone with
> the time and a degree of focus who can get us out of this?
If Hyrum can invest the time, then great, he should do it. But he's
already busy with wc-ng, which fixes a whole lot of other serious
problems (doh!). So our resources are scarce, we have too many problems
to fix.
Nevertheless, we should try to do something as soon as possible.
I can also look into finding time for this in June, though I was
thinking about trying to tackle #1964, actually.
I don't think I can do both. I have no prior experience with much
of anything related to #1964 nor #3242, so either of these would
already mean a huge investment of time for me.
Stefan
Received on 2009-05-29 16:35:25 CEST