Another option is to revert that "big revert commit" in git and continue development. Then people would be able to create pull request without problem...
Just need to be sure that new normal release would not be put to cpan. But it would be possible to put beta/engineering releases like it was between 4.041 and 4.042. Any comments from other people about this idea? On Tuesday 12 September 2017 17:04:18 Patrick M. Galbraith wrote: > Pali, > > Yes, I agree, we'll have to create a fork pre revert and stop > accepting PRs > > How might we allow people time to test the fixes to give them time? > Just have them use the fork, I would assume? > > Regards, > > Patrick > > On 9/12/17 6:27 AM, p...@cpan.org wrote: > > On Tuesday 12 September 2017 05: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. > > > > Hi! > > > > To prove fact that other DBI drivers (e.g. Pg or SQLite) had fixed > > similar/same UTF-8 issue as MySQL has and behave Perl-correctly, I > > would provide test cases so you would see difference between Pg, > > SQLite and mysql DBI drivers. > > > > There are also many modules on cpan which uses mysql DBI driver. > > But I'm not sure if all those modules expects buggy behavior or > > not... > > > >> 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. > > > > If we are going to have UTF-8 fix in DBD::mysql, I would suggest > > one thing right now: > > > > STOP MERGING AND ACCEPTING PULL REQUEST TO GITHUB DBD::MYSQL > > PROJECT! > > > > Reason is simple: Current git master repository at version 4.043 > > (against which are creating new pull requests) is reset to version > > 4.041 and couple of changes, including lot of bug fixes from 4.042 > > are missing > > > > People in 4.043 (and git master) re-discovered 4.041 bugs, which > > were fixed in 4.042 and started to fixing them again, either > > wrongly or in different way. Or just started complaining about > > them, that they are again present. > > > > Those (reverted) UTF-8 commits changes couple of lines, plus other > > fixes depends on it. Once git master repository starts to > > divergent, it would be very hard to incorporate UTF-8 fixes again. > > > > And speaking by myself, for me it would be easier to create a fork > > of DBD::mysql from point before big revert as trying to re-apply > > and rebase those patches on top of master with couple of > > changes...
