Re^3: Perl 5.8.2 thread is much worse

So you had to remove a workaround for a no longer existent bug from your code. Sounds like an overall win to me. I don't see how you can talk about poor QA when the p5p folks explicitly mention that they're aware that the new code is problematic. Apparently they simply deemed the old code so bad that they preferred to toss out unfinished code for this fix-date release than keep the previous stuff.

At least judging by the amount of investigation to prepare your initial post (none, you just complained "my scripts are broken now" - if you made any debugging attempt you certainly didn't mention it) I'd be more inclined to trust the p5p opinion.

Update: I wasn't saying detach were a workaround per se, just that pg put it in "against his will" as he says because it was necessary.

Makeshifts last the longest.

Comment on Re^3: Perl 5.8.2 thread is much worse

Replies are listed 'Best First'.
Re: Re^3: Perl 5.8.2 thread is much worse by pg (Canon) on Dec 27, 2003 at 06:44 UTC
There is no doubt that, to break detach() is absolutely a bug. When it is true that it was a workaround to use detach() in my original code, please remember that it is absolutely valid to detach a thread. I can choose to keep the detach(), and there is nothing wrong with that. Now to those people who wish to detach() their threads, they have to implement a workaround without detach(), and then put detach() back when it is fixed. Is this a "overall win" to us? "I don't see how you can talk about poor QA when the p5p folks explicitly mention that they're aware that the new code is problematic." If they explicitly mentioned that they knew detach() is broken, I would probably say nothing about their QA, but that is simply not the case. After all, it is not me talking about the poor QA, but detach(). "...this fix-date release..." What makes the "fixed date" more important than the quality of the release?	[reply]

Replies are listed 'Best First'.

Re: Re^3: Perl 5.8.2 thread is much worse
by pg (Canon) on Dec 27, 2003 at 06:44 UTC

There is no doubt that, to break detach() is absolutely a bug. When it is true that it was a workaround to use detach() in my original code, please remember that it is absolutely valid to detach a thread. I can choose to keep the detach(), and there is nothing wrong with that.

Now to those people who wish to detach() their threads, they have to implement a workaround without detach(), and then put detach() back when it is fixed. Is this a "overall win" to us?

"I don't see how you can talk about poor QA when the p5p folks explicitly mention that they're aware that the new code is problematic."

If they explicitly mentioned that they knew detach() is broken, I would probably say nothing about their QA, but that is simply not the case. After all, it is not me talking about the poor QA, but detach().

"...this fix-date release..."

What makes the "fixed date" more important than the quality of the release?

[reply]