For the reason of "silence": I've spoken to other users to hear that they have passively withdrawn from this discussion as they are not motivated to be part of a release where concerns about backwards compatibility are ignored. One of the users wrote earlier (replace the word "sector" with "release"):
"When you're dealing with software that's purpose in life is to not corrupt data, and have data there tomorrow, you go out of your way not to break that promise. There's no point in being involved in this sector if you don't care to deliver on that promise." Re-releasing the 4.042 changes will break the contract of a long-standing interface and corrupt all BLOB data when using "do()". These changes do therefore more harm than good. Putting these utf8 changes in the freezer until a suggestion is made that will add the functionality instead of replacing it is not a sin. The PG driver has for instance also a similar issue open without plans to fix it anytime soon. https://rt.cpan.org/Public/Bug/Display.html?id=122991 What is your objection against using the current 4.043 branch and work on outstanding fixes, do a pre-release, a period of time for people to test/try out, then release? On Mon, Nov 6, 2017 at 11:32 PM, Patrick Galbraith <p...@patg.net> wrote: > Pali, > > I totally understand - timing timing - I started a new job and found out I > had to prepare to talk about MySQL/Kubernetes at kubecon, so I apologize, > and didn't plan it that way. Let me re-review those emails and give a > decision, of course, your decision as well. > > As far as maintainer, you are an equal, and if you need to be seen as a > decision maker and we work by consensus with you having equal decision. I'm > glad with that as well because I do appreciate all of your contributions. > I'm sorry for what you mentioned in the past though it was more of a > reaction to deal with "customers" having issues and working panic mode, not > a slight to your efforts. What would you prefer? > > So, what would be ideal for us to move forward is to get the utf8 fixes > into the master branch, then work in the subsequent fixes that came after > June, do a pre-release, a period of time for people to test/try out, then > release. What sort of git gymnastics does this require? What do you think? > > I think the key here to have a single driver that supports both Maria and > MySQL both and not have splintering, and more than anything, provide > stability as well as new features for users. > > Regards, > > Patrick > > > > On 11/05/2017 04:24 AM, p...@cpan.org wrote: > > Hi! > > Have you got replies from people who you informed/asked about that > problems? > > What is needed from you is to decide how to handle problems with > encoding and other bugs reported for DBD-mysql project [1]. > > I sent in previous email some proposed solutions and I'm just waiting > which would be chosen... I just do not like "silence" and no step > forward. Just to note that Dan Book asked month ago for next steps. > > Also, I'm not very happy to see being co-maintainer of DBD::mysql, > specially in this time when nothing happened for 5 months, plus some > people opposed to me and wanted to revert bug fixes and contributions by > me... > > [1] - https://rt.cpan.org/Public/Dist/Display.html?Name=DBD-mysql > > On Friday 03 November 2017 16:17:09 Patrick M. Galbraith wrote: > > Pali, > > Sorry, I wanted to give it time for people, plus have been very busy. > I'm ready, just let me know when we can get code merged back in-- > what do you need me to do? I will need help with this. > > Regards, > > Patrick > > On 11/2/17 1:43 PM, p...@cpan.org wrote: > > On Tuesday 12 September 2017 11:40:31 Patrick M. Galbraith wrote: > > Hi all, > > After talking to Pali and looking at how other drivers have > handled the issue, the best way forward will be to deal with > solving the UTF-8 issue correctly as was attempted in May. This > will be a problem for some, but only due to having to been > accustomed to a work-around that relies on a intermittent and > buggy implementation. The plan is to give ample time to let > people prepare and comment as well as give them a chance to try > the changes and adjust prior to stable release. I'm going to look > through the mailing list and find particularly those who had > problems back in May and June when we tried this before and work > with them in advance of the change. > > DBD::mysql should be on par with all the other DBD drivers and > allow transparent usage regardless of backing RDBMS, and this > really is the only way. It will also allow for other fixes to > proceed and the driver to continue improving and supporting all > versions and enhancements of MySQL and MariaDB. > > Please do give us your thoughts on this as we want to be as > helpful and transparent as possible. > > Thank you! > > Patrick > > Hi! Nearly another two months passed and there is no progress in > unblocking development. > > Currently more people started reporting problems that new versions > of both MySQL and MariaDB cannot be used for building DBD::mysql. > > As I stated two months ago, we are thinking about forking > DBD::mysql as inability to build DBD::mysql with new version of > MySQL or MariaDB is a real problem which needs to be fixed ASAP -- > and not waiting another 6 months. > > >
