Remember, release is not about the tests, it's about releasing good stuff.
agreed. see below.
If you skip the tests but people start using this broken functionality they will report bugs. Why wasting time on that.
maybe somebody will produce a patch and fix it for us ;)
Let's get the stable code out, and then fix that new thing and get it out in the next release.
I disagree with your assessment. if you can prove that removing only the DESTROY logic but _keeping_ the existing tests (and replacing implicit DESTROY calls with $p->destroy) passes, then I would agree with you.
from steve's recent email:
> Basically, this broke: > > my $p = APR::Pool->new; > my $subp = $p->new; > $p->destroy; > > but this worked: > > my $p = APR::Pool->new; > $p->destroy;
if removing the DESTROY implementation causes the first example to pass, then I've obviously done something wrong and the code should get nixed (or fixed if we can figure it out). if it still fails, though, then what you have is a bug elsewhere - removing the subpool tests only mask a deeper problem, and don't keep users from using the existing API to generate segfaults.
so, let's figure out whether it is really the DESTROY logic or a problem with pools in and of themselves before we remove functionality. and the tests ought to stay in either case - otherwise you're just hiding problems that users will stumble upon anyway through normal excercise of the API.
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
