Re: [Dbix-class] 4/5 Why Matt's proposal is a farce

[Peter Rabbitson]

On 10/12/2016 07:19 PM, Matt S Trout wrote:


...my being willing to dogfood some perl6 stuff for minor scripting
of my irssi setup


^^ This is all I said. And yes, I consider it a lapse of judgment to 
dogfood something so fragile even for your own purposes.




should be taken as an endorsement that the code in question is fit
for every day use in general?


I never said "in general" or anything similar.


___
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

Re: [Dbix-class] 4/5 Why Matt's proposal is a farce

[Matt S Trout]

On Wed, Oct 12, 2016 at 06:59:24PM +0200, Peter Rabbitson wrote:
> On 10/12/2016 06:43 PM, Christian Walde wrote:
> >I'm a little confused here. I saw a talk that: Starts with a sentence
> >stating "this is crazy stuff", contains the phrase "hackometer status:
> >melted" and ends on the note of "play with this".
> >
> >How did you get "considered fit for every day use" out of this?
> 
> https://youtu.be/j3r-lKlrrRg?t=1026
> 
> "... And I wanted to use this for IRC scripting, and I am not
> recompiling my entire frigging IRC rig against a different perl in
> order to do that..."
> 
> Seems like a case of everyday use to me.

I'm sorry? Are you seriously saying that you believe that my being willing
to dogfood some perl6 stuff for minor scripting of my irssi setup should
be taken as an endorsement that the code in question is fit for every day
use in general?

Traditionally, one finds ways to dogfood stuff explicitly *because* the code
isn't ready and trying it out oneself is the way to irish mine clear the most
egregious problems, so this interpretation seems deeply strange to me.

-- 
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

___
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

Re: [Dbix-class] 4/5 Why Matt's proposal is a farce

[Christian Walde]

On Wed, 12 Oct 2016 18:59:24 +0200, Peter Rabbitson  
 wrote:



On 10/12/2016 06:43 PM, Christian Walde wrote:

On Tue, 11 Oct 2016 19:27:03 +0200, Peter Rabbitson
 wrote:


For crying out loud: we are talking about the person who considers
this Rube Goldberg machine[11] fit for every day use!!!

[11] https://youtu.be/j3r-lKlrrRg?t=1035


I'm a little confused here. I saw a talk that: Starts with a sentence
stating "this is crazy stuff", contains the phrase "hackometer status:
melted" and ends on the note of "play with this".

How did you get "considered fit for every day use" out of this?


https://youtu.be/j3r-lKlrrRg?t=1026

"... And I wanted to use this for IRC scripting, and I am not  
recompiling my entire frigging IRC rig against a different perl in order  
to do that..."


Seems like a case of everyday use to me.


Thanks for clarifying. It seems like a reasonable interpretation to make,  
though i find the exact intent behind that a little ambiguous. Getting it  
usable in irc could be anything from driving a business on it to making a  
new cowsay in it.


--
With regards,
Christian Walde

___
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

Re: [Dbix-class] 4/5 Why Matt's proposal is a farce

[Peter Rabbitson]

On 10/12/2016 06:43 PM, Christian Walde wrote:

On Tue, 11 Oct 2016 19:27:03 +0200, Peter Rabbitson
 wrote:


For crying out loud: we are talking about the person who considers
this Rube Goldberg machine[11] fit for every day use!!!

[11] https://youtu.be/j3r-lKlrrRg?t=1035


I'm a little confused here. I saw a talk that: Starts with a sentence
stating "this is crazy stuff", contains the phrase "hackometer status:
melted" and ends on the note of "play with this".

How did you get "considered fit for every day use" out of this?


https://youtu.be/j3r-lKlrrRg?t=1026

"... And I wanted to use this for IRC scripting, and I am not 
recompiling my entire frigging IRC rig against a different perl in order 
to do that..."


Seems like a case of everyday use to me.


___
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

Re: [Dbix-class] 4/5 Why Matt's proposal is a farce

[Christian Walde]

On Tue, 11 Oct 2016 19:27:03 +0200, Peter Rabbitson  
 wrote:


For crying out loud: we are talking about the person who considers this  
Rube Goldberg machine[11] fit for every day use!!!


[11] https://youtu.be/j3r-lKlrrRg?t=1035


I'm a little confused here. I saw a talk that: Starts with a sentence  
stating "this is crazy stuff", contains the phrase "hackometer status:  
melted" and ends on the note of "play with this".


How did you get "considered fit for every day use" out of this? Hallway  
track?


--
With regards,
Christian Walde

___
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

Re: [Dbix-class] 4/5 Why Matt's proposal is a farce

[Peter Rabbitson]

On 10/12/2016 02:30 PM, David Cantrell wrote:

On Tue, Oct 11, 2016 at 07:27:03PM +0200, Peter Rabbitson wrote:


- 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.


This is not necessarily a bad thing.

In fact I've done it myself. First I deprecated a feature in the
documentation. Then a while later I made it emit a warning. Then another
while later I got rid of it which, if people were still using the
deprecated feature, made their code die.


I was referring to something completely different. Please read [1] and 
possibly [2] for a more in-depth look into that particular chapter.



Getting rid of the deprecated
features made the code simpler and easier to understand, and so less
likely to be a bug-laden piece of crap.


Or one can simply do something like [3], and (at zero cost to future 
maintenance) prevent an entire class of late-night head scratchers


Cheers

[1] 
https://metacpan.org/pod/release/RJBS/perl-5.24.0/regen/warnings.pl#Fatal-Warnings

[2] https://rt.cpan.org/Public/Bug/Display.html?id=93004
[3] 
https://github.com/dbsrgits/dbix-class/blob/dc7d8991/lib/DBIx/Class/Storage/DBIHacks.pm#L919-L961


___
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

Re: [Dbix-class] 4/5 Why Matt's proposal is a farce

[Matt S Trout]

On Wed, Oct 12, 2016 at 01:30:59PM +0100, David Cantrell wrote:
> On Tue, Oct 11, 2016 at 07:27:03PM +0200, Peter Rabbitson wrote:
> 
> > 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.
> 
> This is not necessarily a bad thing.
> 
> In fact I've done it myself. First I deprecated a feature in the
> documentation. Then a while later I made it emit a warning. Then another
> while later I got rid of it which, if people were still using the
> deprecated feature, made their code die. Getting rid of the deprecated
> features made the code simpler and easier to understand, and so less
> likely to be a bug-laden piece of crap.

In this case, riba's referring to 'use warnings FATAL => ...;', or these
days the specific subet of warnings that 'use strictures 2;' fatalises.

Which is very much a trade-offs situation - I want e.g. an unexpected undef
to cause my code to die(), because 'unexpected' means 'this might be a bug',
and I'd prefer a crash to completing in an unexpected state and risking
data corruption.

I'm also happy to have code that dies on newer perl versions that didn't
previously until patched, because the last time a newly added warning caused
that to happen to a piece of my code, that also exposed a bug.

I'm very conscious of the potential additional inconvenience to users as a
result of this approach, but prefer inconvenience of the form of an
unexpected crash over the increased risk of the code completing successfully
from the POV of the surrounding application while having actually done the
wrong thing.

-- 
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

___
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

Re: [Dbix-class] 4/5 Why Matt's proposal is a farce

[Jess Robinson]

On Tue, 11 Oct 2016 18:27:03 +0100, Peter Rabbitson  
 wrote:



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.



- 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]




.. If anyone wonders why I've been quiet, this may help explain it... This  
is difficult to reply to, so this is as much as you're going to get.


Jess


___
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

Re: [Dbix-class] 4/5 Why Matt's proposal is a farce

[David Cantrell]

On Tue, Oct 11, 2016 at 07:27:03PM +0200, Peter Rabbitson wrote:

> 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.

This is not necessarily a bad thing.

In fact I've done it myself. First I deprecated a feature in the
documentation. Then a while later I made it emit a warning. Then another
while later I got rid of it which, if people were still using the
deprecated feature, made their code die. Getting rid of the deprecated
features made the code simpler and easier to understand, and so less
likely to be a bug-laden piece of crap.

And this is software whose users *must* keep it up to date for it to be
useful. Unlike with DBIx::Class, whose users can quite happily keep
using an old version if they don't want new features, users of
Number::Phone will get wrong results if they don't keep up to date. And
those wrong results will cost them money, because they're using it to do
things like bill their customers and route phone calls.

-- 
David Cantrell | Nth greatest programmer in the world

You can't spell "slaughter" without "laughter"

___
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

[Dbix-class] 4/5 Why Matt's proposal is a farce

[Peter Rabbitson]

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