On Fri, Jul 31, 2009 at 8:59 AM, Stefan Sperling<stsp_at_elego.de> wrote:
> Given this, I'd say the best way to make sure we get a fix for this quickly
> is by providing additional developer resources which focus solely on this
> problem. I see two ways to do this.
> One way is providing help if you have capable developers in-house.
> More contributors are always welcome, and an active and healthy relationship
> to Subversion's developer community can be beneficial in the long-run
> for any business, especially if you use Subversion yourself, but also
> from e.g. a marketing perspective. Don't dismiss the benefits of direct
> involvement in the development process. Oh, and you also get #3242 fixed.
> The other way is to offer to fund an existing developer who can't
> otherwise afford to pick up a task as big as #3242 due to lack of time.
> That might convince someone already familiar with the code base to work
> on this. Since a number of users are affected by this, and most of them
> seem to be corporate users, funding could probably be pooled with some
> coordination between affected parties. The Subversion Corporation
> (http://www.subversion.org) would be the appropriate contact at our end.
Someone should not have fund development to get a bug fix for a
regression that impacts almost all our users. I realize you are not
suggesting that, but it could be interpreted that way.
Mike Pilato has raised this twice in the past:
The problem as I see it is that the solution has become tricky. And
the right answer potentially involves changing our authz behavior.
What we need is to get some people to respond to those threads and
issues to see if we can reach some consensus on whether it is OK to
make those changes. If not, then Mike lays out what needs to be done,
which sounds fairly difficult to program.
In short, this has not been fixed because there is no quick and obvious fix.
Received on 2009-07-31 15:42:19 CEST