On Thursday 09 November 2017 13:01:19 H.Merijn Brand wrote: > On Thu, 9 Nov 2017 12:32:00 +0100, p...@cpan.org wrote: > > > > Satisfy the above - and you do get the privilege of being a maintainer > > > of a central module with 15+ years of history. > > > > Why should I be interested in maintaining something from which users > > want impossible things? > > "I can resist anything! (except temptation)" > > I, like Peter, have backward compatibility high in my goals. > > e.g. I dropped 5.005 supprt on Text::CSV_XS only in June 2012. The > reasons to keep it working under 5.005 was that it was relatively > little extra work. I dropped it, as it seriously blocked further > development and support features my *user-base* asked for. Lucky me > for being part of my own user-base, so I understand the requests. > > In July 2016 I dropped 5.6.0 and 5.6.1 support. Not because it slows > development, but because these two versions do not build anymore and > do not support the modern toolchain. Not because the community or a > part of the community thinks the users should upgrade to a more recent > "stable" version of perl. Yes, I know 5.6.2 is from 2003 and 14 years > old in 6 days and 5.8.0 is even older, but maintaining a module that > serves almost 1000 other modules on CPAN (last time I counted, it was > 997 direct or indirect dependencies) brings a burden of responsibility > > This is how the river works: If I break this module, at least 997 other > modules will break, and that is CPAN only. What about DarkPAN?
I fully understand backward compatibility and ability to use e.g. older versions of perl with new modules on cpan. For example my module Email::Address::XS is just reimplementation of the Email::Address module in C to fix Algorithmic complexity vulnerability and has backward compatible API. And because Email::Address worked with 5.6, I tried to achieve also 5.6 compatibility with my Email::Address::XS module. But DBD::mysql is different thing. Here we are facing two problems: 1) Passing perl Unicode strings is broken, even if some utf8 config option is enabled. This is changing data, see my identity examples which I sent to list. 2) Probably due to history reasons, API between DBD::mysql and perl applications is misused in way, that is atypical for perl itself and insane for pure perl applications. Moreover it is something which cannot be guaranteed to be "stable" as is affected also by modules not relevant to DBD::mysql. And is pseudo-random, but deterministic. Fixing 1) implies breaking 2) and trying to achieve 2) leads to having 1) broken forever and leads to stopped development. Similar/same problem as 2) had also DBD::Pg and DBD::SQLite and here maintainers rather decided to fix Unicode and drop insanity in 2). In previous emails I also send exact versions of DBD::Pg and DBD::SQLite in which was behavior changed. (Modulo one problem in one specific situation which I found in DBD::Pg.) So now we are in situation when some DBI drivers doing one thing (from perl POV correct) and DBD::mysql different. If there are projects which uses both DBD::Pg and DBD::mysql, or DBD::SQLite and DBD::mysql, then their are either broken (because DBD::mysql differs how process non-ASCII due to 2)) or they needs special hacks when MySQL is in use... So what can be done now? We have a DBD::mysql which behaves differently as others DBI drivers, users misuse internals for BLOBs, driver has broken Unicode support which makes it useless now when UTF-8 is mandatory for applications, plus has pseudo-random behavior. I already suggested, look at modules on cpan which uses DBD::mysql and ask authors/maintainers which behavior they expects. Are they really aware how non-ASCII data are handled in DBD::mysql and that it is differently as e.g. DBD::SQLite? We can also send patches to those modules to fix them. I already sent documentation update for DBD::mysql which describe how to achieve correct handling of the BLOB data in both old and Unicode-fixed version of the DBD::mysql. I already said that I can help with fixing code, but nobody was interested. > If you do not want that burden, I'd strongly advice you *NOT* to take > on the job of (co)maintaining DBD::mysql. Period. I already expressed that I do not want to be maintainer of DBD::mysql. IMO problems with 2) are not possible to maintain. > I *see* your wish to improve it (for whatever value of improvement). > This was exactly the reason I took maint on Text::CSV_XS: I wanted, > maybe even required, new features. The original author/maintainer was > not interested and/or motivated enough to do it and he passed the > module on to me. By that time I HAD NO IDEA what the impact of doing so > had. NONE! *I* wanted new feature and improvements, and he agreed. > > It took me years to fully understand the implications of my actions. > > So, currently I test a release on 7+ architectures and over 150 > versions of perl before I release and additionally I test the latest > release against all of those 997 modules if the new release causes any > of those deps to show new failures (compared to the old release). (Some > of these modules are currently un(der)maintained and won't build on > 5.24+ for whatever reason, so if that breaks, it is not my fault. To discover problems I introduced Travis CI checks for different versions of perl, MySQL and MariaDB versions. It is just for x86, but it was automatic for every one commit in repository... Until it was reverted. Last version is there: https://github.com/perl5-dbi/DBD-mysql/blob/1ece6b4b8630a1cf348373aa41cbe5f748dcd62a/.travis.yml#L10 > Additionally I run speed-tests: I compare the last 20 releases for > typical use and compare the speed. If it drops out of the noise range, > that is a blocker to release, even if the new feature request is wanted > by several requestors or communities. > > If you're not up to this challenge, don't do it. There are companies > depending on DBD::mysql, and they won't be your friend if they need to > modify millions lines of code if you find a new API fit better to the > new features thereby breaking old code. Backward compatibility is > important. More than you think. > > How angry would you be if we broke DBI? > > -- > H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ > using perl5.00307 .. 5.27 porting perl5 on HP-UX, AIX, and openSUSE > http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ > http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
