On 10/07/2016 08:40 PM, David Golden wrote:

[...] I have grave reservations about the specific (now) 4-member team
outlined by Matt. The reservations are entirely technical and procedural
in nature [...] I will elaborate on these reservations if necessary

As above, I think hearing your reservations and the rationale behind
them would be valuable input.  It's clear from the comments from the
community so far that stability (however defined) is important to many.
Your thoughts on what would and wouldn't work will help shape the
discussion of future governance.

Words are cheap. Let's look at the record instead: In the past several years mst has been directly responsible ( single-handedly or in part ) for the following:

- Shoving FATAL-ized warnings down CPAN's users throats. After years of incessant pushback finally semi-relented[1], but still continues to insert it into his CPAN projects to this day.

- Advocated for the insertion of a computed goto[2] into the core of Dancer2's routing dispatch[3], making it inherently unsafe, with currently little hope for a fix.

- Advocated for proliferation of Module::Build::Tiny, under the banner of "we need to keep trying new things", leading to massive levels of inconvenience/wasted time for both packagers and end-users.

- Was pivotal in ramming through the questionable ( to say the least ) changes in the Test::More namespace, under the banner of "we are going to try and find out"[4], knowing full well there is no rolling back from this action.

- Is currently salivating to yet again attempt to rewrite SQL::Abstract[5], despite clear signs that this is a bad plan[6] (mst himself seemed to agree with [6] around 2016-05-17)


In order to "balance out" his "enthusiast"[7] tendencies (if this is even possible given mst's personality) Matt proposes:


- ilmari: Decidedly another "ehthusiast". Great at proposing and implementing low-hanging-fruit fixups. Yet loses interest whenever the problem space required a more in-depth solution.

- castaway: Openly decries DBIC[8] for being unlike "... other
bits of CPAN, apart from maybe the ones in core, that attempt to be as
rigorous in their perfection"

- frew: True, the only person in the entire thread so far to echo my understanding of "stability"[9]. Has a very mature approach to software engineering, and while having "enthusiast" leanings as well is able to recognize when it is time to put his tools down. On the down-side: has (understandably) no patience for pesky squabbles, and has expressed unambiguously his involvement won't be "what it used to be"[10]

So in a sense we have the illusion of a committee, and the result will yet again be experiments at the expense of the user base, under a supposedly-well-meaning pretext similar to [4].


Many participants of these threads were very quick to declare "the BDFL model does not work". This despite the fact that virtually all coherent software in the CPAN ecosystem (including /usr/bin/perl itself) are a product of this very model.


Matt promises a better and more careful way going forward. At the same time none of his more recent high-profile actions have even the remote indication of some sort of maturity beyond his 2005-era mindset. For crying out loud: we are talking about the person who considers this Rube Goldberg machine[11] fit for every day use!!!


This is why I remain utterly skeptical. As they say (in Texas I think):
Fool me 5 times in a row...


[1] http://shadow.cat/blog/matt-s-trout/moo-2-strictures-2/
[2] https://metacpan.org/source/MAUKE/Return-MultiLevel-0.04/lib/Return/MultiLevel.pm#L95
[3] https://github.com/PerlDancer/Dancer2/issues/1125#issuecomment-179326519
[4] http://blogs.perl.org/users/chad_exodist_granum/2016/04/test2testbuilder-update-from-the-qah.html#comment-1702921
[5] https://irclog.perlgeek.de/perl6/2016-09-23#i_13264359
[6] https://github.com/dbsrgits/dbix-class/commit/07fadea8d#diff-b1e08875e88f9cfd4c48251700469d84R90
[7] https://youtu.be/A23Xoa5CE7g?t=2363
[8] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96192.html
[9] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012277.html
[10] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012254.html
[11] https://youtu.be/j3r-lKlrrRg?t=1035

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Reply via email to