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

[Paul Beardsell]

Look, I have repeatedly made my thanks evident and plain.  Each of us
contributes to this chain in different ways.  My users depend on me (and
others) for application code.  I depend on you (and others) for database
code.  You depend on Larry Wall (and others) for the Perl environment.
Larry depends on Richard Stallman (and others) for compilers etc.  You get
the picture. There really is no need to get all precious and prickly.

Despite your assertions, I have the code, and I have the diffs.  What you
say is incorrect.  Ty's patch was not applied.

Thanks again for all your constructive work.

Regards,
Paul

Paul Beardsell
Paul at Beardsell.com


2009/10/21 Jens Rehsack <rehsack at googlemail.com>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20091021/34279ed5/attachment.htm>