Supposed fix to #317518: New version of libsql-statement-perl is very, very much slower

Jens Rehsack rehsack at googlemail.com
Wed Oct 21 08:50:04 UTC 2009


2009/10/21 Paul Beardsell <paul at beardsell.com>:
> Jens,
>
> This is the second time that the bug I reported has been said to be fixed.
> The first time (v1.14) the performance had got worse, not better.  It took
> me a lot of effort to work that out.  Installing and uninstalling software
> so as to run benchmarks, with the same data etc etc is time consuming, so
> you will understand my disappointment.

And the development I do in my free time, answering to reported issues etc.
is not consuming time?
Did you understand my disappointment when I say, the patch has been applied
regardless if you can verify it or not? If you don't trust me, you'd
better not use
SQL::Statement or any other of the modules I wrote or applied patches.

> Before doing all that work again I thought it would be interesting to see
> the nature of Ty's patch.  It looked good (worthy of performance testing) to
> me.
>
> But the patch supplied by Ty was not applied.

It was. End of this argue.

>  Now, I am not one of those
> like you spending a lot of time on this and related packages for the benefit
> of others (thank you!), but if we're going to close the bug off and SAY the
> patch has been applied, then it should have been applied.
>
> If the real reason for closing the bug report is that the code is now
> completely re-written in 1.22 and it is impossible to apply the patch, and
> that maybe the new code is quicker than any recent version anyway, then that
> should be the reason quoted for closing the bug, not the reason actually
> given.

The RT was closed when I released 1.17 - and I applied all patches I got.
Either using patch <... or adding by hand the fitting lines.

> I re-iterate:  The patch was not applied to 1.15 (where the important bits
> appear but are commented out) and was similarly not fully applied to 1.18.

You cannot verify. Maybe you should wait a bit, I will checking each release
I made to svn.perl.org and label it. Than you can verify each single release.
At the time of 1.16_* and 1.17 etc. I didn't had an account on svn.perl.org,
that's why I need to do it now (a bit later).

> Therefore I submit it was unlikely to have been applied to 1.16, as reported
> in the bug "fix".  [I cannot find that version of the code, however.]
>
> That's my point:  If the bug is being closed off and the stated reason is
> that the patch has been applied, then the patch must be applied.  It's a
> small but important point, and I labour over it, but I respond to your
> question:  You asked what the purpose of my e-mail was.

And that I'd answered in previous mails. And it's documented in the report.
You can trust in the answers of the reported issues or not. In the latter case,
you didn't trust the author and either you're going to use an alternate solution
or trust you debian package maintainer (he/she can bundle such questions to
me or any other maintainer) or buy commercial support for S:S.
Finally: You can never be sure how a patch get's applied - fully, partially or
first full and than reworked.

The point is: sure, it's not good if some intermediate releases are removed
from CPAN, but space on cpan.org costs money so I'll delete development
releases after a time. When I finished committing the history to svn.cpan.org,
I'm going to delete even more outdated packges.

Best regards,
Jens



More information about the pkg-perl-maintainers mailing list