On Thursday 09 November 2017 10:32:57 Peter Rabbitson wrote: > On 11/09/2017 09:54 AM, p...@cpan.org wrote: > > > >As those people or projects misuse some internals of perl we cannot > >guarantee anything such that which may be broken or changed by updating > >any module from cpan or external source not related to DBD::mysql. > > > > Pali. This "argument" applies to a large portion of CPAN. All JSON variants, > various web frameworks, even things as mundane as math libraries: > https://rt.cpan.org/Public/Bug/Display.html?id=123268
Yes, it applies and people should be aware of it... > >As already stated more times, if there is some code which depends on > >some internals, it should stay conserved in tested version as it can > >break by updating anything (also unrelated). There is no other option > >how to achieve that code stay working and does not corrupt something > >else. > > Pali, this is *not* how CPAN works. Nor is this even how /usr/bin/perl > works. It does not matter if cpan works like this or not. More important is that in any world (does not have to be perl) above statement is truth. Once you are starting depending on some internals, then you must be aware of it that internals may change at anytime if you update one component in ecosystem. > >Maintaining such thing is something what I believe nobody wants. For > >sure I'm not. > > > > I will state several very obvious ( to me ) things, apologies if they seem > condescending: I simply do not know whether the participants on this thread > are talking about the same thing. > > Pali's entire premise is flawed. In the grand scheme of things it makes > absolutely no difference what "maintainers want". Zero. > > What the complaints in this thread are focused on is what the *users* want. As already wrote, if users want or need to depend on internals which are subject to change or which can be changed by something irrelevant to DBD::mysql, maintainers nor any other developers of DBD::mysql cannot do anything with it. The only thing what users can do is not to updating their ecosystem OR fixing their code to not use internals. Basically if somebody is asking for something which is either not possible or hard to achieve, then there would be few or zero people ready to serve such thing. So here I would ask you: Are you going to develop, maintain and ensure these users requirements for DBD::mysql? If not, are you able to find another people who will do it? I spent non-trivial time on looking at current code and I could say that above requirement is really really hard to achieve when DBD::mysql would be actively developed. And because current DBD::mysql is not possible to compile with last MariaDB nor with last (beta) MySQL and fixing these parts needs active development, it means that such requirement is even more hard. So if somebody depends on internals, then is already bound to some MySQL or MariaDB version (last which works with DBD::mysql) and is already locked for upgrading MySQL/MariaDB. > And every maintainer, Pali included, are irrevocably bound by the general > direction of wishes of the userbase. I think last time we did most what we could... > The wishes are roughly ( and in order of inmportance ): > > - Breakage is never silent and is rectified swiftly when reported ( and is > ideally never argued about ) Michiel announced more times changes to list, wrote blog posts, released two (or more?) trial releases to cpan and waited for a longer time before releasing final version. Discussion about patches were on both RT and github open... What else could be done there? > - Upgrades are noneventful as a whole, and are as modular as possible ( i.e. > a DBD upgrade does not drag in Test2 or something similarly non-relevant ) DBD::mysql is just one module, there is not possible to make it modular. > - The overall library seems to move in a "better direction" ( more > performance, less memory use, support for newer protocols, etc ) New versions fixed some problems with both new and older MySQL and MariaDB versions, added more automated tests for different versions. > 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? > If one can't - then the user-base is better off with the module remaining > "unmaintained" ( reusing Pali's terminology ), and Pali's brave-new-world > plan ending up in a different namespace. DBD::MariaDB is an idea. > > Cheers
