Re: DBD::mysql next steps

[Michiel Beijen]

Hi Pali!

On Thu, Nov 16, 2017 at 12:49 PM,   wrote:

> Hi! And what are you going to do with all commits which you reverted in
> 4.043 version? As I remember, months ago you wrote that you reapply
> fixes, but nothing happened. Instead you started merging conflicting
> new pull requests which other people opened on github. This just prevent
> any future reintroduction of fixes which were already done and was
> reverted. Or you going to invent wheel again? I'm really surprised that
> you now want to throw out everything which I did, including security
> fixes for SSL/TLS or new versions of MariaDB/MySQL (with huge test
> setup). Otherwise I do not understand why you have not looked at
> reverted commit yet... Or are you expecting that new after one year I
> should start rebasing all my commits which I did on top of master and
> opening pull requests again and again? Sorry, but this really look that
> you are not interested in new supporting new MariaDB version and now is
> really a good time to create a fork of DBD::mysql which would contains
> support for new MariaDB, huge test coverage and security fixes for
> SSL/TLS.

As you might have seen I'm adding back the commits that were added
between 4.041 and 4.042 piece by piece to the master branch.

I'm trying to prevent breaking stuff so I'm moving slowly.

I'm not expecting you to do any rebasing or sending new pull requests
of code which we had already. I'll be applying the patches myself.
Also, please note that the huge Travis setup and TLS fixes were really
good and I absolutely am going to add this back to master.

That said, I merged https://github.com/perl5-dbi/DBD-mysql/pull/181
which changes the bug tracker location to Github in the META.yml this
morning; we don't need to merge everything exactly in order and
accepting this pull request really does not make it impossible to
later add the patches between 4.041 and 4.042 back to the code base.

And of course we *NEED* to support libmysqlclient of MySQL 8 and also
MariaDB, I can't see us making a new release to CPAN that would *NOT*
support this.

--
Michiel

Re: DBD::mysql next steps

[pali]

On Friday 10 November 2017 10:13:55 Patrick M. Galbraith wrote:
> Greetings all!
> 
> Michiel and I have been talking, weighing options of what course to take in
> dealing with moving forward-- with the goal of both offering both stability
> and the choice to have the latest functionality and bug fixes as well as
> give contributors the opportunity to be part of overall improvements to the
> driver.
> 
> What we are going to do is:
> 
> Add to the connection the ability to turn on proper UTF handling with
> 'mysql_enable_proper_unicode'. This gives the user volition the option to 
> knowingly
> toggle whether they want the new functionality and understand that
> data structures returned or accepted by the driver might be different
> than without this setting.
> 
> The other options had their merits, but we think this will solve the issue
> while keeping the driver unified and prevent divergence.
> 
> Thank you for your input over the last couple months-- we look forward to
> moving ahead!
> 
> Patrick and Michiel
> 

Hi! And what are you going to do with all commits which you reverted in
4.043 version? As I remember, months ago you wrote that you reapply
fixes, but nothing happened. Instead you started merging conflicting
new pull requests which other people opened on github. This just prevent
any future reintroduction of fixes which were already done and was
reverted. Or you going to invent wheel again? I'm really surprised that
you now want to throw out everything which I did, including security
fixes for SSL/TLS or new versions of MariaDB/MySQL (with huge test
setup). Otherwise I do not understand why you have not looked at
reverted commit yet... Or are you expecting that new after one year I
should start rebasing all my commits which I did on top of master and
opening pull requests again and again? Sorry, but this really look that
you are not interested in new supporting new MariaDB version and now is
really a good time to create a fork of DBD::mysql which would contains
support for new MariaDB, huge test coverage and security fixes for
SSL/TLS.

Re: DBD::mysql next steps

[pali]

And I would suggest to disable issue tracker on github as primary bug
tracker (according to DBD::mysql documentation) is on RT and also
probably all problems are reported there. The worst thing which can be
is to have two independent bug trackers, which is current situation.

Re: DBD::mysql next steps

[pali]

On Friday 10 November 2017 10:13:55 Patrick M. Galbraith wrote:
> Greetings all!
> 
> Michiel and I have been talking, weighing options of what course to take in
> dealing with moving forward-- with the goal of both offering both stability
> and the choice to have the latest functionality and bug fixes as well as
> give contributors the opportunity to be part of overall improvements to the
> driver.
> 
> What we are going to do is:
> 
> Add to the connection the ability to turn on proper UTF handling with
> 'mysql_enable_proper_unicode'. This gives the user volition the option to 
> knowingly
> toggle whether they want the new functionality and understand that
> data structures returned or accepted by the driver might be different
> than without this setting.
> 
> The other options had their merits, but we think this will solve the issue
> while keeping the driver unified and prevent divergence.
> 
> Thank you for your input over the last couple months-- we look forward to
> moving ahead!
> 
> Patrick and Michiel

Great! Thank you very much, I'm waiting for a new action which would
bring DBD::mysql back to the active development.

Re: DBD::mysql next steps

[Patrick M. Galbraith]

Darren,

Yes, the other plan definitely had its merits. Credit due to Michiel on 
that plan who really helped lay it out and explain the pros and cons of 
each and helped me to get that idea out.


Kind Regards,

Patrick

On 11/10/17 12:24 PM, Darren Duncan wrote:

I agree in principle with Patrick's plan.

My strong recommendation for continuing development under a different 
module name was based on the assumption (but not the knowledge) that 
the Unicode/Blob problems were rooted in the DBD::mysql codebase in 
such a way that they blocked the ability to use the newer 
MySQL/MariaDB/etc client libraries properly and that maintaining 
support for both behaviors user-configurable would be too difficult to 
do without making bugs worse.


However, I also believe that Patrick's proposal (a single DBD::mysql 
under that name where the incompatible new behavior is toggled on a 
per-connection switch) is actually the best and most elegant solution 
for satisfying all parties under the assumption that there are savvy 
developers who fully understand the problem and are able and willing 
to support such a more-complicated codebase.


-- Darren Duncan

On 2017-11-10 7:13 AM, Patrick M. Galbraith wrote:

Greetings all!

Michiel and I have been talking, weighing options of what course to 
take in
dealing with moving forward-- with the goal of both offering both 
stability

and the choice to have the latest functionality and bug fixes as well as
give contributors the opportunity to be part of overall improvements 
to the

driver.

What we are going to do is:

Add to the connection the ability to turn on proper UTF handling with
'mysql_enable_proper_unicode'. This gives the user volition the 
option to knowingly

toggle whether they want the new functionality and understand that
data structures returned or accepted by the driver might be different
than without this setting.

The other options had their merits, but we think this will solve the 
issue

while keeping the driver unified and prevent divergence.

Thank you for your input over the last couple months-- we look 
forward to

moving ahead!

Patrick and Michiel

Re: DBD::mysql next steps

[Darren Duncan]

I agree in principle with Patrick's plan.

My strong recommendation for continuing development under a different module 
name was based on the assumption (but not the knowledge) that the Unicode/Blob 
problems were rooted in the DBD::mysql codebase in such a way that they blocked 
the ability to use the newer MySQL/MariaDB/etc client libraries properly and 
that maintaining support for both behaviors user-configurable would be too 
difficult to do without making bugs worse.


However, I also believe that Patrick's proposal (a single DBD::mysql under that 
name where the incompatible new behavior is toggled on a per-connection switch) 
is actually the best and most elegant solution for satisfying all parties under 
the assumption that there are savvy developers who fully understand the problem 
and are able and willing to support such a more-complicated codebase.


-- Darren Duncan

On 2017-11-10 7:13 AM, Patrick M. Galbraith wrote:

Greetings all!

Michiel and I have been talking, weighing options of what course to take in
dealing with moving forward-- with the goal of both offering both stability
and the choice to have the latest functionality and bug fixes as well as
give contributors the opportunity to be part of overall improvements to the
driver.

What we are going to do is:

Add to the connection the ability to turn on proper UTF handling with
'mysql_enable_proper_unicode'. This gives the user volition the option to 
knowingly
toggle whether they want the new functionality and understand that
data structures returned or accepted by the driver might be different
than without this setting.

The other options had their merits, but we think this will solve the issue
while keeping the driver unified and prevent divergence.

Thank you for your input over the last couple months-- we look forward to
moving ahead!

Patrick and Michiel