Ben Reser wrote:
>>In general I would agree, however, this bug was pushed out there as a
>>"security fix" and didn't undergo the testing it should have. It seems to
>>me that the problem this fix created ought to be addressed as quickly as
>>it was introduced.
>
> I have no idea what you're talking about here. The fix was developed
> over a month or so. It was not put out quickly nor was it undertested.
> Unless your definition of undertesting is missing a bug.
>
> I'm not inclined to do a 1.0.9 release, baring some sort of data loss
> issue. People that don't want the slow down and don't need the security
> fix can simply run 1.0.7. That's why we don't roll security fixes in
> with a lot of other fixes.
I wouldn't say I feel strongly about it, but I would lean toward
releasing 1.1.1 (and possibly 1.0.9) with a fix. The reason is that
I've been hyping Subversion 1.1 at my company, and everyone has been
excited about upgrading. But the slowdown introduced with the security
fix is a showstopper for us, and the security fix itself is one that we
want to have, so we now have a few choices:
- Stick with 1.0.7 (miss out on 1.1 features and miss the security fix)
- Upgrade to 1.0.8, patched with r11211 (miss 1.1 features, get the
security fix, but run a custom version)
- Upgrade to 1.1.0-rc3 (gain 1.1 features but miss the security fix)
- Upgrade to 1.1.0, patched with r11211 (gain 1.1 features and the
security fix, but run a custom version)
None of these options are too appealing... we'll probably go with the
last option since we want the security fix and 1.1 features, without the
slowdown. That would work, but I'd rather run a 1.1 released version
instead. I suspect there may be others in the same boat, so I think
releasing 1.1.1 soon would be a good idea.
-- Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 4 23:50:36 2004