Skip Menu |

To: perlbug [...] perl.org
CC: zefram [...] fysh.org
Date: Sun, 17 Dec 2017 11:35:13 +0000
From: zefram [...] fysh.org
Subject: BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 3.9k
This is a bug report for perl from zefram@fysh.org, generated with the help of perlbug 1.41 running under perl 5.27.7. ----------------------------------------------------------------- [Please describe your issue here] The smartmatch changes merged in commit da4e040f42421764ef069371d77c008e6b801f45 break some CPAN modules. The first known breakages, because they're dual-life and had to be customised in blead, are autodie [rt.cpan.org #123898] and experimental [rt.cpan.org #123899]. [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- Site configuration information for perl 5.27.7: Configured by zefram at Sun Dec 17 11:32:35 GMT 2017. Summary of my perl5 (revision 5 version 27 subversion 7) configuration: Commit id: da4e040f42421764ef069371d77c008e6b801f45 Platform: osname=linux osvers=3.16.0-4-amd64 archname=x86_64-linux-thread-multi uname='linux barba.rous.org 3.16.0-4-amd64 #1 smp debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 gnulinux ' config_args='-des -Dprefix=/home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52 -Duselargefiles -Dusethreads -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dusedevel -Uversiononly -Ui_db -DDEBUGGING' hint=recommended useposix=true d_sigaction=define useithreads=define usemultiplicity=define use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cc' ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2' optimize='-O2 -g' cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='4.9.2' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='cc' ldflags =' -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.19.so so=so useshrplib=true libperl=libperl.so gnulibc_version='2.19' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags='-Wl,-E -Wl,-rpath,/home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/5.27.7/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC' lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector-strong' --- @INC for perl 5.27.7: /home/zefram/usr/perl/pg/lib /home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/site_perl/5.27.7/x86_64-linux-thread-multi /home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/site_perl/5.27.7 /home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/5.27.7/x86_64-linux-thread-multi /home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/5.27.7 --- Environment for perl 5.27.7: HOME=/home/zefram LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH=/home/zefram/usr/perl/pg LOGDIR (unset) PATH=/home/zefram/usr/perl/util:/home/zefram/pub/x86_64-unknown-linux-gnu/bin:/home/zefram/pub/common/bin:/usr/bin:/bin:/usr/local/bin:/usr/games PERL5LIB=/home/zefram/usr/perl/pg/lib PERLDOC=-oman PERL_BADLANG (unset) SHELL=/usr/bin/zsh
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
To: perl5-porters [...] perl.org
Date: Mon, 18 Dec 2017 00:23:06 +0100
Also affected: ETHER/Try-Tiny-0.28.tar.gz -- andreas
To: perl5-porters [...] perl.org
Date: Tue, 19 Dec 2017 21:18:26 +0100
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Download (untitled) / with headers
text/plain 284b
Also affected: RURBAN/B-Keywords-1.15.tar.gz DROLSKY/DateTime-Format-Strptime-1.74.tar.gz FREW/DBIx-Class-Candy-0.005003.tar.gz PERLANCAR/Perinci-Sub-DepChecker-0.11.tar.gz ABIGAIL/Regexp-Common-2017060201.tar.gz FREW/Syntax-Keyword-Junction-0.003008.tar.gz -- andreas
Date: Wed, 20 Dec 2017 19:49:17 +0100
To: perl5-porters [...] perl.org
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Download (untitled) / with headers
text/plain 472b
Also affected: POWERMAN/Async-Defer-v1.0.0.tar.gz MNF/JavaScript-Prepare-v0.1.tar.gz SCHWIGON/Data-DPath-0.57.tar.gz DOHERTY/Lingua-Boolean-0.008.tar.gz TOBYINK/Lingua-Boolean-Tiny-0.007.tar.gz TOBYINK/match-simple-0.010.tar.gz RJBS/Number-Tolerant-1.708.tar.gz PEVANS/Tangence-0.24.tar.gz XIONG/developer-tools/Test-Ranger-v0.0.4.tar.gz PERLANCAR/Org-Parser-0.54.tar.gz CHILTS/XML-Assert-0.03.tar.gz BDFOY/Unicode-Tussle-1.111.tar.gz -- andreas
From: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
To: Perl5 Porters <perl5-porters [...] perl.org>
CC: bugs-bitbucket [...] rt.perl.org
Date: Wed, 20 Dec 2017 20:16:37 +0100
Download (untitled) / with headers
text/plain 414b
On Sun, Dec 17, 2017 at 12:35 PM, Zefram <perlbug-followup@perl.org> wrote:
Show quoted text
The smartmatch changes merged in commit
da4e040f42421764ef069371d77c008e6b801f45 break some CPAN modules.
The first known breakages, because they're dual-life and had to be
customised in blead, are autodie [rt.cpan.org #123898] and experimental
[rt.cpan.org #123899].

Smart::Match and threads::lite are also affected.

Leon
Date: Fri, 22 Dec 2017 05:05:18 +0100
To: perl5-porters [...] perl.org
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Also affected, found by Slaven: DBAURAIN/Bio-MUST-Drivers-0.173510.tar.gz -- andreas
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Sat, 23 Dec 2017 10:12:01 +0100
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 517b
Also affected: BMORROW/Config-TinyDNS-1.tar.gz SHARYANTO/Data-Dump-Partial-0.05.tar.gz PERLANCAR/Data-Unixish-1.56.tar.gz JALDHAR/DateTime-Calendar-Discordian-1.0.tar.gz CFAERBER/DateTime-Format-DBI-0.041.tar.gz JROCKWAY/Devel-InPackage-0.01.tar.gz SEANO/Exception-Resumable-0.91.tar.gz LEMBARK/Exporter-Proxy-1.8.tar.gz SIFUKURT/File-Butler-v4.0.0.tar.gz AERDAN/File-XDG-0.04.tar.gz DCONWAY/IO-Prompter-0.004014.tar.gz PATCH/Operator-Util-0.05.tar.gz JROCKWAY/Package-FromData-0.01.tar.gz -- andreas
From: Slaven Rezic <slaven [...] rezic.de>
Date: Sat, 23 Dec 2017 10:45:39 +0100
To: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 1.3k
Also affected: * CHRISBR/Test-Mockify-1.0.tar.gz * DCONWAY/Lingua-EN-Inflexion-0.001006.tar.gz * JJNAPIORK/Catalyst-Runtime-5.90115.tar.gz * LEONT/experimental-0.019.tar.gz * MAROS/MooseX-App-1.39.tar.gz * PERLANCAR/DBIx-Diff-Schema-0.090.tar.gz * PERLANCAR/Data-Sah-0.88.tar.gz * PERLANCAR/Module-XSOrPP-0.11.tar.gz * PERLANCAR/Perinci-Sub-DepChecker-0.11.tar.gz * PERLANCAR/Perl-Stripper-0.10.tar.gz * PERLANCAR/Progress-Any-Output-TermProgressBarColor-0.23.tar.gz * PERLANCAR/Text-ANSITable-0.49.tar.gz * PERLANCAR/Unix-Passwd-File-0.250.tar.gz * PJF/autodie-2.29.tar.gz * TOBYINK/lexical-underscore-0.004.tar.gz * VPIT/Scope-Upper-0.30.tar.gz (compilation error) Sorry for any possible duplicates --- the many lists are hard to track. I did not omit dual-life modules which are already fixed in core. Actually I did not do a thorough check if these are really affected because of #132594, or due to other reasons. BTW, I stopped my regular 5.27.7 smoker runs and switched back to the last bleadperl without any major breakages (5.27.5). I won't also do complete CPAN checks like I used to do with former bleadperl versions. Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de Berlin Perl Mongers - http://berlin.pm.org
From: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Sat, 23 Dec 2017 13:39:22 +0100
To: Slaven Rezic <slaven [...] rezic.de>
CC: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.9k
On Sat, Dec 23, 2017 at 10:45 AM, Slaven Rezic <slaven@rezic.de> wrote:
Show quoted text
Also affected:

      * CHRISBR/Test-Mockify-1.0.tar.gz
      * DCONWAY/Lingua-EN-Inflexion-0.001006.tar.gz
      * JJNAPIORK/Catalyst-Runtime-5.90115.tar.gz
      * LEONT/experimental-0.019.tar.gz
      * MAROS/MooseX-App-1.39.tar.gz
      * PERLANCAR/DBIx-Diff-Schema-0.090.tar.gz
      * PERLANCAR/Data-Sah-0.88.tar.gz
      * PERLANCAR/Module-XSOrPP-0.11.tar.gz
      * PERLANCAR/Perinci-Sub-DepChecker-0.11.tar.gz
      * PERLANCAR/Perl-Stripper-0.10.tar.gz
      * PERLANCAR/Progress-Any-Output-TermProgressBarColor-0.23.tar.gz
      * PERLANCAR/Text-ANSITable-0.49.tar.gz
      * PERLANCAR/Unix-Passwd-File-0.250.tar.gz
      * PJF/autodie-2.29.tar.gz
      * TOBYINK/lexical-underscore-0.004.tar.gz
      * VPIT/Scope-Upper-0.30.tar.gz (compilation error)

Sorry for any possible duplicates --- the many lists are hard to track.
I did not omit dual-life modules which are already fixed in core.
Actually I did not do a thorough check if these are really affected
because of #132594, or due to other reasons.

BTW, I stopped my regular 5.27.7 smoker runs and switched back to the
last bleadperl without any major breakages (5.27.5). I won't also do
complete CPAN checks like I used to do with former bleadperl versions.
 
IMNSHO this breakage is irresponsible and madness. None of this is necessary at all: we can easily enable the old behavior under use 5.010 .. 5.026,and and the new one on use 5.028+, that way we could have new potentially better smartmatch without fucking over everyone who has been using it over the past decade.

I really don't get how to got into this situation. It feels to me like in search for some sense of purity we lost all consideration for our user base. We had a little discussion on what the new behavior should look like, but none at all about deal with the transition. It's almost like we're deliberately trying to fuck ourselves over.

Leon


From: James E Keenan <jkeenan [...] pobox.com>
Date: Sat, 23 Dec 2017 09:00:00 -0500
CC: Leon Timmermans <fawaka [...] gmail.com>, Slaven Rezic <slaven [...] rezic.de>, Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
To: Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132594] BBC smartmatchda4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 2.6k
On 12/23/2017 07:39 AM, Leon Timmermans wrote: Show quoted text
> On Sat, Dec 23, 2017 at 10:45 AM, Slaven Rezic <slaven@rezic.de > <mailto:slaven@rezic.de>> wrote: > > Also affected: > >       * CHRISBR/Test-Mockify-1.0.tar.gz >       * DCONWAY/Lingua-EN-Inflexion-0.001006.tar.gz >       * JJNAPIORK/Catalyst-Runtime-5.90115.tar.gz >       * LEONT/experimental-0.019.tar.gz >       * MAROS/MooseX-App-1.39.tar.gz >       * PERLANCAR/DBIx-Diff-Schema-0.090.tar.gz >       * PERLANCAR/Data-Sah-0.88.tar.gz >       * PERLANCAR/Module-XSOrPP-0.11.tar.gz >       * PERLANCAR/Perinci-Sub-DepChecker-0.11.tar.gz >       * PERLANCAR/Perl-Stripper-0.10.tar.gz >       * PERLANCAR/Progress-Any-Output-TermProgressBarColor-0.23.tar.gz >       * PERLANCAR/Text-ANSITable-0.49.tar.gz >       * PERLANCAR/Unix-Passwd-File-0.250.tar.gz >       * PJF/autodie-2.29.tar.gz >       * TOBYINK/lexical-underscore-0.004.tar.gz >       * VPIT/Scope-Upper-0.30.tar.gz (compilation error) > > Sorry for any possible duplicates --- the many lists are hard to track. > I did not omit dual-life modules which are already fixed in core. > Actually I did not do a thorough check if these are really affected > because of #132594, or due to other reasons. > > BTW, I stopped my regular 5.27.7 smoker runs and switched back to the > last bleadperl without any major breakages (5.27.5). I won't also do > complete CPAN checks like I used to do with former bleadperl versions. >
That seems wise. The data I've been assembling on the CPAN-river-1000 (presented in other posts) shows considerably increased breakage from the November and December releases. Show quoted text
> IMNSHO this breakage is irresponsible and madness. None of this is > necessary at all: we can easily enable the old behavior under use 5.010 > .. 5.026,and and the new one on use 5.028+, that way we could have new > potentially better smartmatch without fucking over everyone who has been > using it over the past decade. > > I really don't get how to got into this situation. It feels to me like > in search for some sense of purity we lost all consideration for our > user base. We had a little discussion on what the new behavior should > look like, but none at all about deal with the transition. It's almost > like we're deliberately trying to fuck ourselves over. >
I concur. We are now less than one-month away from the point in the annual dev cycle after which nothing "contentious" may be committed to blead (Jan 20 2018). All this breakage is contentious by definition. Thank you very much. Jim Keenan
Date: Sat, 23 Dec 2017 14:44:37 +0000
To: Perl5 Porters <perl5-porters [...] perl.org>
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 2.7k
Leon Timmermans wrote: Show quoted text
> we can easily enable the old behavior under use 5.010 .. >5.026,and and the new one on use 5.028+,
That's neither sensible nor really workable. It would not be sensible because it would involve retaining and maintaining all of the overcomplex old behaviour indefinitely. It would have to stay in the documentation, and users would have to be aware of it as a feature they might see used in Perl programs. It would be a substantial burden all round. The feature has been marked experimental for years precisely so that we would not be obliged to keep all of this; it was explicitly intended that we would in fact change it. This is what experimental status is for. Hypothetically, if we did implement dual behaviour, that still wouldn't just avoid this breakage. If smartmatch overloading is a single hook, such that 5.10 code and 5.28 code using their respective smartmatch operators invoke the same smartmatch overload methods, then there is a problem in constructing higher-order smartmatch objects, such as Smart::Match's junctions. Smartmatching means different things for different code, so it's no longer possible to pass a smartmatcher across an API boundary and have that have a consistent meaning. Does any() take 5.10 smartmatchers? That's how its arguments will be interpreted if Smart::Match remains unchanged, written in 5.10 code. How do you do any() on 5.28 smartmatchers? What if Smart::Match is reimplemented? And so on; the variations are obvious. The only way to keep the behaviour really compatible would be for 5.10 smartmatch and 5.28 smartmatch to have separate overload hooks, but then you need duplicates of all of Smart::Match, and people will get them confused. Show quoted text
> without fucking over everyone who has been >using it over the past decade.
If 5.10-style smartmatch is so significantly used that it's not acceptable to remove it, this is the wrong point at which to raise that issue. It's not an argument for not changing an ill-designed experimental feature; it's an argument for taking it out of experimental status. Show quoted text
> We had a little discussion on what the new behavior should look like, >but none at all about deal with the transition.
It seemed quite obvious how to transition. We determined long ago that the changes we'd make would be extensive, and would leave little compatibility with the old version of the feature. It's an experimental feature, so we're free to change things without a deprecation cycle. Hence the most reasonable course of action is a one-time breaking change with no attempt to be compatible. Furthermore, if there are any other incompatible changes we might be interested in then it's best to group them all together into this one big break of compatibility. -zefram
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Date: Sun, 24 Dec 2017 15:07:57 +0100
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 263b
Also affected: LEMBARK/Parallel-Queue-3.6.tar.gz SGLADKOV/Redis-CappedCollection-1.10.tar.gz MAJENSEN/REST-Neo4p-0.3020.tar.gz BBYRD/sanity-1.03.tar.gz MATIU/SQL-Bibliosoph-2.55.tar.gz TAPPER/Tapper-Installer-5.0.0.tar.gz DOY/Try-0.03.tar.gz -- andreas
To: perl5-porters [...] perl.org
Date: Sun, 24 Dec 2017 19:43:34 +0200
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 3.9k
I'll let Leon to respond to the technical details. I want to address the overall breakage this has caused. On first blush, it seems like too many things are breaking. On second thought, smart match had always been experimental. However, my current thoughts are back to "too many things are breaking." This breakage is considerable and the harm it will have on CPAN is vast. While we do reserve the right to change the syntax (because it's experimental), it does not mean we must do it right now. We should exercise judgment and err on the side of caution. The most telling email for me on this thread was Slaven saying he stopped smoke testing on 5.27.7 because too many things were breaking due to this. I think we need to take a step back, revert this change, and figure out a plan to move forward[1]. Smart match has waited this long, it can wait another release in hopes of getting it right. (Perhaps we will also find alternatives for "whereis" and "whereso" meanwhile.) [1] This is currently only a suggestion, but unless someone comes up with something better, this is what we should do. On 12/23/2017 04:44 PM, Zefram wrote: Show quoted text
> Leon Timmermans wrote:
>> we can easily enable the old behavior under use 5.010 .. >> 5.026,and and the new one on use 5.028+,
> That's neither sensible nor really workable. It would not be sensible > because it would involve retaining and maintaining all of the overcomplex > old behaviour indefinitely. It would have to stay in the documentation, > and users would have to be aware of it as a feature they might see > used in Perl programs. It would be a substantial burden all round. > The feature has been marked experimental for years precisely so that > we would not be obliged to keep all of this; it was explicitly intended > that we would in fact change it. This is what experimental status is for. > > Hypothetically, if we did implement dual behaviour, that still wouldn't > just avoid this breakage. If smartmatch overloading is a single hook, > such that 5.10 code and 5.28 code using their respective smartmatch > operators invoke the same smartmatch overload methods, then there is > a problem in constructing higher-order smartmatch objects, such as > Smart::Match's junctions. Smartmatching means different things for > different code, so it's no longer possible to pass a smartmatcher across > an API boundary and have that have a consistent meaning. Does any() > take 5.10 smartmatchers? That's how its arguments will be interpreted > if Smart::Match remains unchanged, written in 5.10 code. How do you > do any() on 5.28 smartmatchers? What if Smart::Match is reimplemented? > And so on; the variations are obvious. The only way to keep the behaviour > really compatible would be for 5.10 smartmatch and 5.28 smartmatch to > have separate overload hooks, but then you need duplicates of all of > Smart::Match, and people will get them confused. >
>> without fucking over everyone who has been >> using it over the past decade.
> If 5.10-style smartmatch is so significantly used that it's not acceptable > to remove it, this is the wrong point at which to raise that issue. > It's not an argument for not changing an ill-designed experimental > feature; it's an argument for taking it out of experimental status. >
>> We had a little discussion on what the new behavior should look like, >> but none at all about deal with the transition.
> It seemed quite obvious how to transition. We determined long ago > that the changes we'd make would be extensive, and would leave little > compatibility with the old version of the feature. It's an experimental > feature, so we're free to change things without a deprecation cycle. > Hence the most reasonable course of action is a one-time breaking change > with no attempt to be compatible. Furthermore, if there are any other > incompatible changes we might be interested in then it's best to group > them all together into this one big break of compatibility. > > -zefram
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Sun, 24 Dec 2017 11:10:52 -0700
To: Sawyer X <xsawyerx [...] gmail.com>, perl5-porters [...] perl.org
On 12/24/2017 10:43 AM, Sawyer X wrote: Show quoted text
> I'll let Leon to respond to the technical details. I want to address the > overall breakage this has caused. > > On first blush, it seems like too many things are breaking. On second > thought, smart match had always been experimental. However, my current > thoughts are back to "too many things are breaking." This breakage is > considerable and the harm it will have on CPAN is vast. While we do > reserve the right to change the syntax (because it's experimental), it > does not mean we must do it right now. We should exercise judgment and > err on the side of caution. > > The most telling email for me on this thread was Slaven saying he > stopped smoke testing on 5.27.7 because too many things were breaking > due to this. > > I think we need to take a step back, revert this change
+1 , and figure out Show quoted text
> a plan to move forward[1]. Smart match has waited this long, it can wait > another release in hopes of getting it right. (Perhaps we will also find > alternatives for "whereis" and "whereso" meanwhile.) > > [1] This is currently only a suggestion, but unless someone comes up > with something better, this is what we should do. > > > On 12/23/2017 04:44 PM, Zefram wrote:
>> Leon Timmermans wrote:
>>> we can easily enable the old behavior under use 5.010 .. >>> 5.026,and and the new one on use 5.028+,
>> That's neither sensible nor really workable. It would not be sensible >> because it would involve retaining and maintaining all of the overcomplex >> old behaviour indefinitely. It would have to stay in the documentation, >> and users would have to be aware of it as a feature they might see >> used in Perl programs. It would be a substantial burden all round. >> The feature has been marked experimental for years precisely so that >> we would not be obliged to keep all of this; it was explicitly intended >> that we would in fact change it. This is what experimental status is for. >> >> Hypothetically, if we did implement dual behaviour, that still wouldn't >> just avoid this breakage. If smartmatch overloading is a single hook, >> such that 5.10 code and 5.28 code using their respective smartmatch >> operators invoke the same smartmatch overload methods, then there is >> a problem in constructing higher-order smartmatch objects, such as >> Smart::Match's junctions. Smartmatching means different things for >> different code, so it's no longer possible to pass a smartmatcher across >> an API boundary and have that have a consistent meaning. Does any() >> take 5.10 smartmatchers? That's how its arguments will be interpreted >> if Smart::Match remains unchanged, written in 5.10 code. How do you >> do any() on 5.28 smartmatchers? What if Smart::Match is reimplemented? >> And so on; the variations are obvious. The only way to keep the behaviour >> really compatible would be for 5.10 smartmatch and 5.28 smartmatch to >> have separate overload hooks, but then you need duplicates of all of >> Smart::Match, and people will get them confused. >>
>>> without fucking over everyone who has been >>> using it over the past decade.
>> If 5.10-style smartmatch is so significantly used that it's not acceptable >> to remove it, this is the wrong point at which to raise that issue. >> It's not an argument for not changing an ill-designed experimental >> feature; it's an argument for taking it out of experimental status. >>
>>> We had a little discussion on what the new behavior should look like, >>> but none at all about deal with the transition.
>> It seemed quite obvious how to transition. We determined long ago >> that the changes we'd make would be extensive, and would leave little >> compatibility with the old version of the feature. It's an experimental >> feature, so we're free to change things without a deprecation cycle. >> Hence the most reasonable course of action is a one-time breaking change >> with no attempt to be compatible. Furthermore, if there are any other >> incompatible changes we might be interested in then it's best to group >> them all together into this one big break of compatibility. >> >> -zefram
>
Subject: Re: [perl #132594] BBC smartmatchda4e040f42421764ef069371d77c008e6b801f45
Date: Sun, 24 Dec 2017 13:50:52 -0500
To: Sawyer X <xsawyerx [...] gmail.com>, perl5-porters [...] perl.org
From: James E Keenan <jkeenan [...] pobox.com>
Download (untitled) / with headers
text/plain 1.6k
On 12/24/2017 12:43 PM, Sawyer X wrote: Show quoted text
> I'll let Leon to respond to the technical details. I want to address the > overall breakage this has caused. > > On first blush, it seems like too many things are breaking. On second > thought, smart match had always been experimental. However, my current > thoughts are back to "too many things are breaking." This breakage is > considerable and the harm it will have on CPAN is vast. While we do > reserve the right to change the syntax (because it's experimental), it > does not mean we must do it right now. We should exercise judgment and > err on the side of caution. > > The most telling email for me on this thread was Slaven saying he > stopped smoke testing on 5.27.7 because too many things were breaking > due to this. > > I think we need to take a step back, revert this change, and figure out > a plan to move forward[1]. Smart match has waited this long, it can wait > another release in hopes of getting it right. (Perhaps we will also find > alternatives for "whereis" and "whereso" meanwhile.) > > [1] This is currently only a suggestion, but unless someone comes up > with something better, this is what we should do. >
+1 As the data which I have been posting suggests, we already have a lot of CPAN breakage to deal with over the balance of this development cycle, and over the next four weeks in particular. That's going to be a cognitive load on all of us, particularly since many people won't be able to focus on it until after the holidays. So if we can avoid a lot of breakage and downstream frustration by only taking measured steps forward, I say let's do so. Thank you very much. Jim Keenan
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
To: perl5-porters [...] perl.org
Date: Sun, 24 Dec 2017 22:49:34 +0100
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Download (untitled) / with headers
text/plain 1.5k
On 12/24/2017 06:43 PM, Sawyer X wrote: Show quoted text
> > On first blush, it seems like too many things are breaking. On second > thought, smart match had always been experimental.
Give me a fucking break! Is the period between 5.10 and 5.18 "ancient history" enough, for you to top-post-declare how "smart match has always been experimental? [1] What is the end-game here? In a short time you went from "I have no great plans when it comes to changes to the Perl core"[2] to full blown "make perl great again". Do you *still* feel that /usr/bin/perl ( and its users ) can go fuck itself[3], even after a year on the job? I am not writing this email because I expect you to *change* or because there is a way to make things work with you at the helm. I am writing this because I am pissed. You are an excellent speaker ( whenever you talk about a subject you know ), a superb story-teller, and overall an all around decent human being. And all of this is tainted and gone forever, because you bought into the narrative that "anyone can be president". So today, instead of all the positive stuff above, you are an absolute, irredeemable failure and embarrassment as a technical leader and as a user advocate, feverishly butchering one of the oldest mainstream languages. And for what? Please grow a pair and resign. [1] https://metacpan.org/pod/distribution/perl/pod/perl5180delta.pod#The-smartmatch-family-of-features-are-now-experimental [2] https://www.nntp.perl.org/group/perl.perl5.porters/2016/04/msg236028.html [3] https://youtu.be/M-VKSCgIgo0?t=2425
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Sun, 24 Dec 2017 17:04:02 -0700
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>, perl5-porters [...] perl.org
From: Karl Williamson <public [...] khwilliamson.com>
On 12/24/2017 02:49 PM, Peter Rabbitson wrote: Show quoted text
> Please grow a pair and resign
-1
From: Tomasz Konojacki <me [...] xenu.pl>
To: perl5-porters [...] perl.org
Date: Mon, 25 Dec 2017 02:02:10 +0100
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 956b
On Sun, 24 Dec 2017 22:49:34 +0100 Peter Rabbitson <rabbit-p5p@rabbit.us> wrote: Show quoted text
> Is the period between 5.10 and 5.18 "ancient history" enough, for you to top-post-declare how "smart match has always been experimental? [1]
While I don't agree with the rest of this post, it's an *extremely* important point. Smartmatch and given/when aren't typical experimental features. They were introduced in 5.10 and they indeed did *not* warn until 5.18. Those features received widespread adoption years before they started warning. On CPAN alone there are thousands of uses of ~~ and given/when and I'm fairly certain that situation in darkpan is even worse. Huge portion of perl users aren't using anything never than 5.16.3 (which is the version RHEL 7 ships). Most of them are completely unaware of its current status and continue to use it in new code. I think that smartmatch changes should be reverted and we need *much* more discussion about them.
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
CC: perl5-porters [...] perl.org
Date: Sun, 24 Dec 2017 20:14:40 -0500
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 735b
* Peter Rabbitson <rabbit-p5p@rabbit.us> [2017-12-24T16:49:34] Show quoted text
> So today, instead of all the positive stuff above, you are an absolute, > irredeemable failure and embarrassment as a technical leader and as a user > advocate, feverishly butchering one of the oldest mainstream languages. And > for what? > > Please grow a pair and resign.
If you want to have the conversation you're starting in this thread, this is the right place to start it. This is not the right tenor to take, starting reasonably with a complaint about a falsehood, ramping up toward hyperbole, and ending with a crude and sexist remark. "Just anybody can do the job" isn't made any better by tacking on "if they're willing to suffer verbal abuse." -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
To: perl5-porters [...] perl.org
Date: Mon, 25 Dec 2017 06:21:39 +0000
Download (untitled) / with headers
text/plain 359b
Sawyer X wrote: Show quoted text
>I think we need to take a step back, revert this change, and figure out >a plan to move forward[1].
If we can't accept this kind of CPAN breakage then we have no way forward short of deprecation, and experimental status (about which smartmatch has been warning for much longer than a deprecation cycle) would seem to have no value. -zefram
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>, perl5-porters [...] perl.org
Date: Mon, 25 Dec 2017 11:47:39 +0200
Download (untitled) / with headers
text/plain 2.2k
I do not enjoy you picking the one sentence you want to respond to, especially when it is the opposite of the complete point I am making. I clarified that I think it should be reverted, but you looked for me beginning with the counter point so you could have your opening to say what you wanted. Now considering I've resolved to reverting it, what is the point you're trying to drive? Convincing me to do what I said we should? Beyond this, as I've said to anyone else (and stand by), if you cannot make your point without spewing sexist or otherwise offensive behavior, please take it offline. Or, you know, learn to speak like an adult. On 12/24/2017 11:49 PM, Peter Rabbitson wrote: Show quoted text
> On 12/24/2017 06:43 PM, Sawyer X wrote:
>> >> On first blush, it seems like too many things are breaking. On second >> thought, smart match had always been experimental.
> > Give me a fucking break! > > Is the period between 5.10 and 5.18 "ancient history" enough, for you > to top-post-declare how "smart match has always been experimental? [1] > > What is the end-game here? In a short time you went from "I have no > great plans when it comes to changes to the Perl core"[2] to full > blown "make perl great again". Do you *still* feel that /usr/bin/perl > ( and its users ) can go fuck itself[3], even after a year on the job? > > I am not writing this email because I expect you to *change* or > because there is a way to make things work with you at the helm. I am > writing this because I am pissed. You are an excellent speaker ( > whenever you talk about a subject you know ), a superb story-teller, > and overall an all around decent human being. And all of this is > tainted and gone forever, because you bought into the narrative that > "anyone can be president". > > So today, instead of all the positive stuff above, you are an > absolute, irredeemable failure and embarrassment as a technical leader > and as a user advocate, feverishly butchering one of the oldest > mainstream languages. And for what? > > Please grow a pair and resign. > > [1] > https://metacpan.org/pod/distribution/perl/pod/perl5180delta.pod#The-smartmatch-family-of-features-are-now-experimental > [2] > https://www.nntp.perl.org/group/perl.perl5.porters/2016/04/msg236028.html > [3] https://youtu.be/M-VKSCgIgo0?t=2425
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Mon, 25 Dec 2017 12:40:50 +0200
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On 12/25/2017 08:21 AM, Zefram wrote: Show quoted text
> Sawyer X wrote:
>> I think we need to take a step back, revert this change, and figure out >> a plan to move forward[1].
> If we can't accept this kind of CPAN breakage then we have no way forward > short of deprecation, and experimental status (about which smartmatch > has been warning for much longer than a deprecation cycle) would seem > to have no value.
Any CPAN breakage of this magnitude needs to be weighed against the value it provides in the short term and in the long term, as well as any damage of neglecting it includes. In this case, there is little loss in not making his change at the moment, even if we take the slippery slope perspective that "now experimental needs to be deprecated." This breakage is simply too much for us to ignore or accept for just providing a different smart match. As for the slipper slope argument, I think this argument suggests we "make a point" of it, and I do not think that something we should ever do. We shouldn't be "making a point" with our changes to clarify what "experimental" means or to defend its meaning. Same for "deprecated." We follow-up on deprecation because things have been deprecated for a reason, other than clarifying what "deprecation"' means.
From: Leon Timmermans <fawaka [...] gmail.com>
CC: Perl5 Porters <perl5-porters [...] perl.org>
To: Zefram <zefram [...] fysh.org>
Date: Mon, 25 Dec 2017 15:18:01 +0100
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 1.6k
On Mon, Dec 25, 2017 at 7:21 AM, Zefram <zefram@fysh.org> wrote:
Show quoted text
Sawyer X wrote:
>I think we need to take a step back, revert this change, and figure out
>a plan to move forward[1].

If we can't accept this kind of CPAN breakage then we have no way forward
short of deprecation, and experimental status (about which smartmatch
has been warning for much longer than a deprecation cycle) would seem
to have no value.

There are a few factors here that dramatically reduce the value-for-breakage ratio.

The first is that the level of breakage in smartmatch creates more problems and solves less of them than they could. The problem with it is that it's a 27-way dispatch table: I'm pretty sure we can break «REGEX ~~ HASH» without serious repercussions; but the same is not true of «$foo ~~ "foo"» (that said, actual data would be way more valuable than my anecdotes). A 4-5 way table guided by what features people actually use could give us something that we can explain without breaking people's expectations unnecessarily. Pareto's principle applies here.

The second problem is that the switch feature it provides no way to write code that works on both 5.26 and 5.28 (this really should have been a design requirement), which is effectively equivalent to removing it entirely. Whatever we do we are stuck to when in one way or another.

Thirdly, this process can be made more gradual. Having the 20+ paths that we would break emit deprecation warnings first would ease the transition.

Lastly, what happened to the idea of experimenting on CPAN?

So no, I don't think this kind of breakage is acceptable. That doesn't mean I oppose all change.

Leon
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Mon, 25 Dec 2017 20:08:50 +0000
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
CC: perl5-porters [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 897b
On Sun, Dec 24, 2017 at 10:49:34PM +0100, Peter Rabbitson wrote: Show quoted text
> So today, instead of all the positive stuff above, you are an absolute, > irredeemable failure and embarrassment as a technical leader and as a user > advocate, feverishly butchering one of the oldest mainstream languages. And > for what?
As someone who has been using Perl since 1992, and who has been working on the perl core since 2001, I utterly disagree with every part of your inflammatory and unevidenced statement above. -- No man treats a motor car as foolishly as he treats another human being. When the car will not go, he does not attribute its annoying behaviour to sin, he does not say, You are a wicked motorcar, and I shall not give you any more petrol until you go. He attempts to find out what is wrong and set it right. -- Bertrand Russell, Has Religion Made Useful Contributions to Civilization?
From: Aaron Crane <arc [...] cpan.org>
CC: Perl5 Porters <perl5-porters [...] perl.org>
To: Sawyer X <xsawyerx [...] gmail.com>
Date: Wed, 27 Dec 2017 11:45:37 +0000
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 375b
Sawyer X <xsawyerx@gmail.com> wrote: Show quoted text
> I think we need to take a step back, revert this change, and figure out > a plan to move forward[1]. Smart match has waited this long, it can wait > another release in hopes of getting it right.
+1. There's far too much breakage here for us to countenance releasing anything akin to what's currently in blead as 5.28. -- Aaron Crane
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Wed, 27 Dec 2017 11:46:37 +0000
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
CC: Perl5 Porters <perl5-porters [...] perl.org>
From: Aaron Crane <arc [...] cpan.org>
Download (untitled) / with headers
text/plain 688b
[Speaking as a moderator] Peter Rabbitson <rabbit-p5p@rabbit.us> wrote: Show quoted text
> So today, instead of all the positive stuff above, you are an absolute, > irredeemable failure and embarrassment as a technical leader and as a user > advocate, feverishly butchering one of the oldest mainstream languages. And > for what?
Peter, we do not permit personal attacks on perl5-porters. Please take this as a formal warning, in accordance with our documented Standards of Conduct[1], that this behaviour is unacceptable, and that a repetition of it will result in you being banned from the list. [1] https://metacpan.org/pod/distribution/perl/pod/perlpolicy.pod#STANDARDS-OF-CONDUCT -- Aaron Crane
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Wed, 27 Dec 2017 13:40:22 +0100
To: perl5-porters [...] perl.org
CC: arc [...] cpan.org
On 12/27/2017 12:46 PM, Aaron Crane wrote: Show quoted text
> [Speaking as a moderator] > > Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
>> So today, instead of all the positive stuff above, you are an absolute, >> irredeemable failure and embarrassment as a technical leader and as a user >> advocate, feverishly butchering one of the oldest mainstream languages. And >> for what?
> > Peter, we do not permit personal attacks on perl5-porters. Please take > this as a formal warning, in accordance with our documented Standards > of Conduct[1], that this behaviour is unacceptable, and that a > repetition of it will result in you being banned from the list. >
In order for the warning to be acknowledged by its receiver, common sense requires an explicit highlight of the violation. The part you quoted *specifically* speaks of the pumpkin's job performance. I explicitly avoided making negative statements about his personal character, in fact I explicitly spelled out quite the opposite. Please clarify your concerns as a moderator. Cheers
From: Aaron Crane <arc [...] cpan.org>
Date: Wed, 27 Dec 2017 13:26:14 +0000
CC: Perl5 Porters <perl5-porters [...] perl.org>
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 2.4k
Peter Rabbitson <rabbit-p5p@rabbit.us> wrote: Show quoted text
> On 12/27/2017 12:46 PM, Aaron Crane wrote:
>> >> [Speaking as a moderator] >> >> Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
>>> >>> So today, instead of all the positive stuff above, you are an absolute, >>> irredeemable failure and embarrassment as a technical leader and as a >>> user >>> advocate, feverishly butchering one of the oldest mainstream languages. >>> And >>> for what?
>> >> Peter, we do not permit personal attacks on perl5-porters. Please take >> this as a formal warning, in accordance with our documented Standards >> of Conduct[1], that this behaviour is unacceptable, and that a >> repetition of it will result in you being banned from the list.
> > In order for the warning to be acknowledged by its receiver, common sense > requires an explicit highlight of the violation. > > The part you quoted *specifically* speaks of the pumpkin's job performance. > I explicitly avoided making negative statements about his personal > character, in fact I explicitly spelled out quite the opposite. > > Please clarify your concerns as a moderator.
The Standards of Conduct read as follows: * Always be civil. * Heed the moderators. Civility is simple: stick to the facts while avoiding demeaning remarks and sarcasm. It is not enough to be factual. You must also be civil. While civility is required, kindness is encouraged; if you have any doubt about whether you are being civil, simply ask yourself, "Am I being kind?" and aspire to that. If the list moderators tell you that you are not being civil, carefully consider how your words have appeared before responding in any way. Were they kind? You may protest, but repeated protest in the face of a repeatedly reaffirmed decision is not acceptable. Unacceptable behavior will result in a public and clearly identified warning. Repeated unacceptable behavior will result in removal from the mailing list and revocation of rights to update rt.perl.org. Phrases like "irredeemable failure", "embarrassment", and "feverishly butchering" are demeaning. They are not civil, and they are certainly not kind. To be clear: I am reaffirming my decision that your behaviour above was unacceptable, and I will not engage in further discussion of that decision. If you don't see your comments as uncivil and unkind, all I can suggest is that in future you seek input from other people on any draft messages before sending them. -- Aaron Crane
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
CC: Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Aaron Crane <arc [...] cpan.org>
Date: Wed, 27 Dec 2017 17:34:23 +0100
Download (untitled) / with headers
text/plain 652b
Show quoted text
>>>>> On Wed, 27 Dec 2017 13:26:14 +0000, Aaron Crane <arc@cpan.org> said:
Show quoted text
> Phrases like "irredeemable failure", "embarrassment", and "feverishly > butchering" are demeaning. They are not civil, and they are certainly > not kind.
Show quoted text
> To be clear: I am reaffirming my decision that your behaviour above > was unacceptable, and I will not engage in further discussion of that > decision. If you don't see your comments as uncivil and unkind, all I > can suggest is that in future you seek input from other people on any > draft messages before sending them.
moderation-- # please learn to look away when you are not needed -- andreas
From: Dan Book <grinnz [...] gmail.com>
To: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
CC: Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
Date: Wed, 27 Dec 2017 12:29:39 -0500
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 963b
On Wed, Dec 27, 2017 at 11:34 AM, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
Show quoted text
>>>>> On Wed, 27 Dec 2017 13:26:14 +0000, Aaron Crane <arc@cpan.org> said:

  > Phrases like "irredeemable failure", "embarrassment", and "feverishly
  > butchering" are demeaning. They are not civil, and they are certainly
  > not kind.

  > To be clear: I am reaffirming my decision that your behaviour above
  > was unacceptable, and I will not engage in further discussion of that
  > decision. If you don't see your comments as uncivil and unkind, all I
  > can suggest is that in future you seek input from other people on any
  > draft messages before sending them.

moderation-- # please learn to look away when you are not needed


I disagree, this was quite needed. Peter's comments, specifically how they were presented, are not conducive to rational discussion and contribute to a hostile environment. Just my opinion.

-Dan

From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Date: Wed, 27 Dec 2017 12:38:37 -0500
To: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
CC: Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 679b
* Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> [2017-12-27T11:34:23] Show quoted text
> moderation-- # please learn to look away when you are not needed
I found your brief message ambiguous. Could you clarify whether you mean: 1. Everything here was civil, and this is the kind of tone of conversation that people contributing to p5 should accept. Moderation is sometimes required, but here it was not. 2. Moderation itself is a bad idea, as it inhibits useful conversation. 3. Moderation is sometimes required. Other times, in the face of incivility, the moderators should look away so that somebody who needs to be berated can be. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

Date: Thu, 28 Dec 2017 00:18:47 +0100
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
CC: Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 1.5k
Show quoted text
>>>>> On Wed, 27 Dec 2017 12:38:37 -0500, Ricardo Signes <perl.p5p@rjbs.manxome.org> said:
Show quoted text
> * Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> [2017-12-27T11:34:23]
>> moderation-- # please learn to look away when you are not needed
Show quoted text
> I found your brief message ambiguous.
Show quoted text
> Could you clarify whether you mean:
Show quoted text
> 1. Everything here was civil, and this is the kind of tone of conversation > that people contributing to p5 should accept. Moderation is sometimes > required, but here it was not.
Show quoted text
> 2. Moderation itself is a bad idea, as it inhibits useful conversation.
Show quoted text
> 3. Moderation is sometimes required. Other times, in the face of > incivility, the moderators should look away so that somebody who needs to > be berated can be.
Well, no, sorry, none looks appropriate. Rather these: 4. Moderation can come in many flavours, some of which are better than others. 5. A moderation system like on p5p where a single person can define that certain phrases shall be punished with a life-long ban, is not one of the better ones. 6. The incriminated posting was already rejected by yourself and several others and Sawyer had answered in sovereignty (at least did I perceive it as such) and there was already a chance that the discourse could go on. No need for moderation at all. 7. We have to deal with a highly problematic blead branch with an unprecendented level of breakage. I find it double problematic when moderation kicks in while we have a huge mess to deal with anyway. -- andreas
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Date: Wed, 27 Dec 2017 18:45:57 -0500
CC: Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 1.5k
* Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> [2017-12-27T18:18:47] Show quoted text
> >>>>> On Wed, 27 Dec 2017 12:38:37 -0500, Ricardo Signes > >>>>> <perl.p5p@rjbs.manxome.org> said:
>
> > I found your brief message ambiguous. > > Could you clarify whether you mean: > > [options]
> > Well, no, sorry, none looks appropriate. Rather these:
Thanks, I meant to include "Or something else" and forgot. Show quoted text
> 5. A moderation system like on p5p where a single person can define that > certain phrases shall be punished with a life-long ban, is not one of > the better ones.
This is not really what we have at all. I think there has been one long-term ban issued, outside the rules of the system, by me, after long and sustained incivility. In all other cases, what you describe is not what happens. Show quoted text
> 7. We have to deal with a highly problematic blead branch with an > unprecendented level of breakage. I find it double problematic when > moderation kicks in while we have a huge mess to deal with anyway.
Here is another way to look at it: The project manager is already dealing with a load of crap, and piling abuse on top of complaint is doubly stressful. Complaints must be welcomed. Abuse must be turned away. Having a standard of behavior is a way to ensure that the job is obnoxious only for *necessary* reasons. Following through on the policy every time it is warranted makes it clear that it is a routine, and the most effective way to avoid the hassle of hearing about it is to keep a civil tongue in the first place. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

From: Leon Timmermans <fawaka [...] gmail.com>
To: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
Date: Thu, 28 Dec 2017 05:51:27 +0100
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 671b
On Thu, Dec 28, 2017 at 12:18 AM, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
Show quoted text
7. We have to deal with a highly problematic blead branch with an
   unprecendented level of breakage. I find it double problematic when
   moderation kicks in while we have a huge mess to deal with anyway.

Apparently we have a process of moderation, but no process of language design whatsoever. That's pretty damn ironic, don't you think?

We can stop people from saying unkind things, but how are we going to prevent repeats of this utter fuck-up, given that this "process" could have only resulted in a fuck-up?

Are we going to politely destroy perl?

Leon
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Thu, 28 Dec 2017 02:56:19 -0500
CC: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Leon Timmermans <fawaka [...] gmail.com>
From: Dan Book <grinnz [...] gmail.com>


On Dec 27, 2017 11:53 PM, "Leon Timmermans" <fawaka@gmail.com> wrote:
Show quoted text
On Thu, Dec 28, 2017 at 12:18 AM, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
7. We have to deal with a highly problematic blead branch with an
   unprecendented level of breakage. I find it double problematic when
   moderation kicks in while we have a huge mess to deal with anyway.

Apparently we have a process of moderation, but no process of language design whatsoever. That's pretty damn ironic, don't you think?

We can stop people from saying unkind things, but how are we going to prevent repeats of this utter fuck-up, given that this "process" could have only resulted in a fuck-up?

Are we going to politely destroy perl?

Leon

I don't understand why these topics need to be conflated, and don't find that ironic whatsoever. This list has had a straightforward moderation process for a long time, something that takes very different expertise and procedures to execute effectively than language design. Can we focus on how that can be improved?

-Dan
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Thu, 28 Dec 2017 03:28:22 -0500
CC: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Leon Timmermans <fawaka [...] gmail.com>
From: Dan Book <grinnz [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k


On Dec 27, 2017 11:53 PM, "Leon Timmermans" <fawaka@gmail.com> wrote: Show quoted text

Are we going to politely destroy perl?
Show quoted text


Now, I agree that there is some flaw in the process here and these changes were not ready to be merged. But this is a funny thing people keep saying. That making changes, or making mistakes, is killing Perl.

Outside our little echo chamber most think Perl is dead. They think that because they don't know it's still being used, or still being developed. They think it's abandoned. Some of this is because of Perl 6, or that period of time where it really wasn't being developed. Some of it is because it's been outshined in popularity and buzzwords by the next three big things, which by the way, C and Java and the like don't directly compete with. But they're not saying it's dead because it broke some compatibility.

The reality is that there is no absolute one decision to make in every situation. Managing this language's continued development is a complex balancing act and the continued implications that there are simple answers and one person or another is instead sabotaging Perl are dishonest outlets for dissatisfaction that do no favors to anyone.

-Dan
Date: Thu, 28 Dec 2017 22:57:22 +1300
CC: Leon Timmermans <fawaka [...] gmail.com>, Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Dan Book <grinnz [...] gmail.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Kent Fredric <kentfredric [...] gmail.com>
Download (untitled) / with headers
text/plain 1.2k
On 28 December 2017 at 21:28, Dan Book <grinnz@gmail.com> wrote: Show quoted text
>
Show quoted text
> Outside our little echo chamber most think Perl is dead. They think that > because they don't know it's still being used, or still being developed.
The people who think Perl is dead do not matter what so ever. They're allowed to be wrong. The only people who matter are the people who are already using Perl, and the people who want to use Perl in the future. Changing what Perl is to suit the first group, while making it useless to the second group, pretty much invalidates the point of even having different programming languages. If the design objective of Perl is to be another Ruby or JavaScript, well, why don't we just use those languages then? "Popularity" is not a meaningful metric on its own, because you can be popular due to being popular, not due to being objectively decent. ( Paying attention to politics should make this abundantly clear ) If people want to think Ruby or JavaScript are "cooler" than Perl or "more modern", cool, they can do that. But those are languages where people who presently use Perl frequently find too chaotic to be worth their time investment. Making Perl more chaotic to be cool like them is simply corroding the remaining reasons to use Perl. -- Kent KENTNL - https://metacpan.org/author/KENTNL
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Thu, 28 Dec 2017 11:38:19 +0100
CC: Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 1.7k
Show quoted text
>>>>> On Wed, 27 Dec 2017 18:45:57 -0500, Ricardo Signes <perl.p5p@rjbs.manxome.org> said:
Show quoted text
>> 5. A moderation system like on p5p where a single person can define that >> certain phrases shall be punished with a life-long ban, is not one of >> the better ones.
Show quoted text
> This is not really what we have at all. I think there has been one long-term > ban issued, outside the rules of the system, by me, after long and sustained > incivility. In all other cases, what you describe is not what happens.
Darn, I stand corrected. I only recently learned about the long-term ban and misunderstood it as the normal case. Maybe it would be a good idea to reset the one long-term ban now. I don't think it still serves a good purpose. Show quoted text
>> 7. We have to deal with a highly problematic blead branch with an >> unprecendented level of breakage. I find it double problematic when >> moderation kicks in while we have a huge mess to deal with anyway.
Show quoted text
> Here is another way to look at it: The project manager is already dealing with > a load of crap, and piling abuse on top of complaint is doubly stressful. > Complaints must be welcomed. Abuse must be turned away. Having a standard of > behavior is a way to ensure that the job is obnoxious only for *necessary* > reasons.
Show quoted text
> Following through on the policy every time it is warranted makes it clear that > it is a routine, and the most effective way to avoid the hassle of hearing > about it is to keep a civil tongue in the first place.
Granted, this is a way to look at it. I'd still prefer that the moderation routine should rather kick in as a last ressort than too soon, but given that the harm is smaller than I had thought, I see no value in fighting over it. Thanks for the correction, -- andreas
From: Aaron Crane <arc [...] cpan.org>
Date: Thu, 28 Dec 2017 12:46:59 +0000
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote: Show quoted text
> 5. A moderation system like on p5p where a single person can define that > certain phrases shall be punished with a life-long ban, is not one of > the better ones. > > 6. The incriminated posting was already rejected by yourself and several > others and Sawyer had answered in sovereignty (at least did I > perceive it as such) and there was already a chance that the > discourse could go on. No need for moderation at all. > > 7. We have to deal with a highly problematic blead branch with an > unprecendented level of breakage. I find it double problematic when > moderation kicks in while we have a huge mess to deal with anyway.
Thank you for clarifying your position, Andreas, and for subsequently accepting a correction about the nature of the bans that moderators can impose. I'm not seeking to continue "fighting over" this matter (as your subsequent message puts it), but I've spent the last day thinking hard about it, and you level some specific criticisms that I'd like to respond to. There are also some aspects of my views on the wider topic of moderation that I think it would be helpful for me to set out clearly. First and foremost, I stand by my reading of Peter's comments as uncivil and unacceptable, and by my decision to respond as moderator with a formal warning, in accordance with our standards of conduct. You describe our moderation system as one "where a single person can define that certain phrases shall be punished", and I read this description as a specific characterisation of my actions as moderator in this matter. I reject any contention that Peter's message required close textual analysis of individual phrases to reach a conclusion that it was uncivil; the entire tenor of it was fundamentally a personal attack. Your point 6 seems to be suggesting that, if any moderator replies to any message as an individual, rather than ex officio as moderator, that should automatically cause the message to be treated as acceptable. I disagree strongly with that: one of the reasons we have a panel of moderators is so that no one person has to take responsibility for doing all the unpleasant work of moderation. In the specific case that you raise of Sawyer replying, I note also that there is a conflict of interest if someone bearing the brunt of a personal attack can also respond to that attack as a moderator. You continue by saying that "there was already a chance that the discourse could go on". This suggests you consider that the motivation for having standards of conduct is merely to allow debate to continue somehow. A consequence of that position is that, as long as *some* debate continues, abusive and hurtful behaviour could or even should be permitted to go unchecked. Again, I disagree fervently. I consider behaviour of this sort to be unconditionally unacceptable, regardless of who displays it, the context of the discussion, and whether any other debate continues. The more general views I want to set out hinge on the reasons why we have standards of conduct, and moderators who attempt to ensure they're adhered to. We hold ourselves to standards of conduct that allow us all to come to the best solutions we can, in an environment of mutual respect and assistance. This is especially true of problems without a single obvious right answer, and where a wide variety of options and perspectives are supported by experienced, passionate proponents. We hold ourselves to standards of conduct that allow us to contribute to the consideration of difficult problems without having to worry about whether we're going to bear the brunt of an unpleasant outburst. We hold ourselves to these standards of conduct partly to make it clear to people who are not (yet) active members of our community that, should they choose to take part, they will be welcomed and respected, and that they can expect to do so without having to absorb or defend themselves against hurtful comments — because *all* those who take part are defended by the structures and institutions we have put in place for that purpose. -- Aaron Crane
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
To: Leon Timmermans <fawaka [...] gmail.com>
CC: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
Date: Thu, 28 Dec 2017 09:56:07 -0500
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 1.1k
* Leon Timmermans <fawaka@gmail.com> [2017-12-27T23:51:27] Show quoted text
> Apparently we have a process of moderation, but no process of language > design whatsoever. That's pretty damn ironic, don't you think?
When you can boil language design down to something as simple as "Be civil," please let us know. Show quoted text
> We can stop people from saying unkind things, but how are we going to > prevent repeats of this utter fuck-up, given that this "process" could have > only resulted in a fuck-up? > > Are we going to politely destroy perl?
This is a really bizarre post, Leon. I don't get it. We're going to prevent repeated errors by acknowledging when errors occur, discussing what happened, and trying to avoid them. Zero steps in that process require abuse. This seems like a non-abusive post saying "this is a disaster and we need to stop and figure out what we're doing": https://www.nntp.perl.org/group/perl.perl5.porters/2017/12/msg248329.html Good job, poster! It got a reply in a day saying, "Yes, this is a problem, let's undo this and think about it harder." More posts like that one, pushing for consideration and improvement, seem like a great idea. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Thu, 28 Dec 2017 18:13:31 +0100
To: Dan Book <grinnz [...] gmail.com>
CC: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 588b
On Thu, Dec 28, 2017 at 8:56 AM, Dan Book <grinnz@gmail.com> wrote:
Show quoted text
I don't understand why these topics need to be conflated

Thanks for pointing out this fundamental difference in perception. It's a rather important issue, I think it deserves a thread of its own. I promise I will come back to this.

Show quoted text
, and don't find that ironic whatsoever.

Civility is an essential tool towards not burning out developers, but it's not a goal of p5p by itself. The development of the Perl language is the main goals of this list. How is it not ironic that we've forgotten how to do that?

Leon
From: Leon Timmermans <fawaka [...] gmail.com>
Date: Thu, 28 Dec 2017 18:25:56 +0100
CC: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 1.1k
On Thu, Dec 28, 2017 at 3:56 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
Show quoted text
* Leon Timmermans <fawaka@gmail.com> [2017-12-27T23:51:27]
> Apparently we have a process of moderation, but no process of language
> design whatsoever. That's pretty damn ironic, don't you think?

When you can boil language design down to something as simple as "Be civil,"
please let us know.

We can't, but we can at least do this much more conciously.
 
Show quoted text
> We can stop people from saying unkind things, but how are we going to
> prevent repeats of this utter fuck-up, given that this "process" could have
> only resulted in a fuck-up?
>
> Are we going to politely destroy perl?

This is a really bizarre post, Leon.  I don't get it.

I posted in anger and I shouldn't have and I regret that. I'm sorry about that.
 
Show quoted text
We're going to prevent repeated errors by acknowledging when errors occur,
discussing what happened, and trying to avoid them.

I really don't feel like that has happened. Saying "it broke too much of CPAN so we reverted" barely touches the issue at hand here. There's no taking ownership in that.

Leon
CC: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Leon Timmermans <fawaka [...] gmail.com>
Date: Thu, 28 Dec 2017 13:53:15 -0500
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 560b
* Leon Timmermans <fawaka@gmail.com> [2017-12-28T12:25:56] Show quoted text
> > We're going to prevent repeated errors by acknowledging when errors occur, > > discussing what happened, and trying to avoid them.
> > I really don't feel like that has happened. Saying "it broke too much of > CPAN so we reverted" barely touches the issue at hand here. There's no > taking ownership in that.
I think the process started, and (as you suggest) it needs to continue, because (a) it isn't done and (b) it will need to happen again next time we think something went wrong. -- rjbs
From: demerphq <demerphq [...] gmail.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
CC: Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porteros <perl5-porters [...] perl.org>
To: Dave Mitchell <davem [...] iabyn.com>
Date: Thu, 28 Dec 2017 19:56:58 +0100
Download (untitled) / with headers
text/plain 642b
On 25 December 2017 at 21:08, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Sun, Dec 24, 2017 at 10:49:34PM +0100, Peter Rabbitson wrote:
>> So today, instead of all the positive stuff above, you are an absolute, >> irredeemable failure and embarrassment as a technical leader and as a user >> advocate, feverishly butchering one of the oldest mainstream languages. And >> for what?
> > As someone who has been using Perl since 1992, and who has been working on > the perl core since 2001, I utterly disagree with every part of your > inflammatory and unevidenced statement above.
+1 Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Fri, 29 Dec 2017 08:50:40 +1300
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
CC: Leon Timmermans <fawaka [...] gmail.com>, Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
From: Kent Fredric <kentfredric [...] gmail.com>
Download (untitled) / with headers
text/plain 787b
On 29 December 2017 at 03:56, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: Show quoted text
> * Leon Timmermans <fawaka@gmail.com> [2017-12-27T23:51:27]
>> Apparently we have a process of moderation, but no process of language >> design whatsoever. That's pretty damn ironic, don't you think?
> > When you can boil language design down to something as simple as "Be civil," > please let us know.
"Create certainties" For example: Making a change that creates uncertainty, by breaking historically expected behaviour of a language, and in turn, making the future of any given construct in perl uncertain for future releases, is analogous to "incivility" It should be considered like a personal attack on the existing codebases. ( I tried ) -- Kent KENTNL - https://metacpan.org/author/KENTNL
Date: Thu, 28 Dec 2017 15:28:58 -0500
To: Kent Fredric <kentfredric [...] gmail.com>
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Leon Timmermans <fawaka [...] gmail.com>, Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Dan Book <grinnz [...] gmail.com>
Download (untitled) / with headers
text/plain 978b
On Thu, Dec 28, 2017 at 2:50 PM, Kent Fredric <kentfredric@gmail.com> wrote:
Show quoted text
On 29 December 2017 at 03:56, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> * Leon Timmermans <fawaka@gmail.com> [2017-12-27T23:51:27]
>> Apparently we have a process of moderation, but no process of language
>> design whatsoever. That's pretty damn ironic, don't you think?
>
> When you can boil language design down to something as simple as "Be civil,"
> please let us know.

"Create certainties"

For example: Making a change that creates uncertainty, by breaking
historically expected behaviour of a language, and in turn, making the
future of any given construct in perl uncertain for future releases,
is analogous to "incivility"

It should be considered like a personal attack on the existing codebases.

( I tried )


That's a nice start for your personal favorite aspect, but doesn't encompass 1/10th of what such 'policies' need to cover.

-Dan 
To: Leon Timmermans <fawaka [...] gmail.com>, Perl5 Porters <perl5-porters [...] perl.org>
Date: Thu, 28 Dec 2017 12:34:48 -0800
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Karen Etheridge <perl [...] froods.org>
Download (untitled) / with headers
text/plain 1.3k


On Wed, Dec 27, 2017 at 8:51 PM, Leon Timmermans <fawaka@gmail.com> wrote:
Show quoted text
We can stop people from saying unkind things, but how are we going to prevent repeats of this utter fuck-up, given that this "process" could have only resulted in a fuck-up?

Are we going to politely destroy perl
​?
 

To expand on these points a bit, I think the process failures we had here include:


- introduction of a breaking change in syntax late in the development cycle (the cutoff for contentious changes is in less than a month, which gives little time to resolve breakage downstream - so at this point in the cycle such breakage should be *small* and *contained*)

- changes were not apparently pushed to a smoke-me branch first, where we could have assessed the amount of downstream breakage and then discussed what to do next
 (I would suggest that syntax changes *must always* be smoked first before merging to blead)
- changes were not committed in a rebased branch, which (as previously discussed) makes bisections more difficult, and also complicates the now-inevitable reversion process

- introduction of user-facing syntax changes to a well-known-to-be-controversial feature without discussion of the proposal in the greater community (outside of just p5p) of the new keywords and their function


These are all things we should improve in our process.


respectfully,
Karen Etheridge

CC: Dave Mitchell <davem [...] iabyn.com>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porteros <perl5-porters [...] perl.org>
To: demerphq <demerphq [...] gmail.com>
Date: Thu, 28 Dec 2017 18:05:30 -0600
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Download (untitled) / with headers
text/plain 688b
On Thu, Dec 28, 2017 at 12:56 PM, demerphq <demerphq@gmail.com> wrote: Show quoted text
> On 25 December 2017 at 21:08, Dave Mitchell <davem@iabyn.com> wrote:
>> On Sun, Dec 24, 2017 at 10:49:34PM +0100, Peter Rabbitson wrote:
>>> So today, instead of all the positive stuff above, you are an absolute, >>> irredeemable failure and embarrassment as a technical leader and as a user >>> advocate, feverishly butchering one of the oldest mainstream languages. And >>> for what?
>> >> As someone who has been using Perl since 1992, and who has been working on >> the perl core since 2001, I utterly disagree with every part of your >> inflammatory and unevidenced statement above.
> > +1 > > Yves
Me three.
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Thu, 28 Dec 2017 18:46:32 -0600
CC: Kent Fredric <kentfredric [...] gmail.com>, Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Leon Timmermans <fawaka [...] gmail.com>, Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Dan Book <grinnz [...] gmail.com>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Download (untitled) / with headers
text/plain 2.1k
On Thu, Dec 28, 2017 at 2:28 PM, Dan Book <grinnz@gmail.com> wrote: Show quoted text
> On Thu, Dec 28, 2017 at 2:50 PM, Kent Fredric <kentfredric@gmail.com> wrote:
>> >> On 29 December 2017 at 03:56, Ricardo Signes <perl.p5p@rjbs.manxome.org> >> wrote:
>> > * Leon Timmermans <fawaka@gmail.com> [2017-12-27T23:51:27]
>> >> Apparently we have a process of moderation, but no process of language >> >> design whatsoever. That's pretty damn ironic, don't you think?
>> > >> > When you can boil language design down to something as simple as "Be >> > civil," >> > please let us know.
>> >> "Create certainties" >> >> For example: Making a change that creates uncertainty, by breaking >> historically expected behaviour of a language, and in turn, making the >> future of any given construct in perl uncertain for future releases, >> is analogous to "incivility" >> >> It should be considered like a personal attack on the existing codebases.
I don't buy the analogy. Personal attacks can only happen to persons. We should respect the people who maintain downstream code and be very cautious about incompatible changes, but there's no reason to mix that up with the rules of discussion on the mailing list. I would also like to point out that while civility is free, maintaining 100% backward compatibility can be very expensive. Show quoted text
>> ( I tried ) >>
> > That's a nice start for your personal favorite aspect, but doesn't encompass > 1/10th of what such 'policies' need to cover.
But this isn't language design; it's change management. Which is something that *can* be partially addressed by policy, and perhaps there are some things that should be changed or added in that regard. However, I would caution folks from trying to generalize too much from a situation that is surely unique. I don't recall any other time in the history of Perl that a feature was considered so horribly broken by the people who had invested a lot of time in trying to fix it that it became flagged experimental several years after release. So let's sort out the current situation before we get on a legislative bandwagon and make ordinary life impossible because one exceptional thing happened.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 919b
On Thu, 28 Dec 2017 16:46:54 -0800, craig.a.berry@gmail.com wrote: Show quoted text
> But this isn't language design; it's change management. Which is > something that *can* be partially addressed by policy, and perhaps > there are some things that should be changed or added in that regard. > However, I would caution folks from trying to generalize too much from > a situation that is surely unique. I don't recall any other time in > the history of Perl that a feature was considered so horribly broken > by the people who had invested a lot of time in trying to fix it that > it became flagged experimental several years after release. So let's > sort out the current situation before we get on a legislative > bandwagon and make ordinary life impossible because one exceptional > thing happened.
Thank you. That’s the most thoughtful statement made so far in this thread. I couldn’t agree more. -- Father Chrysostomos
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
CC: Leon Timmermans <fawaka [...] gmail.com>, Perl5 Porters <perl5-porters [...] perl.org>
To: Karen Etheridge <perl [...] froods.org>
Date: Thu, 28 Dec 2017 22:23:51 -0600
On Thu, Dec 28, 2017 at 2:34 PM, Karen Etheridge <perl@froods.org> wrote: Show quoted text
> > > On Wed, Dec 27, 2017 at 8:51 PM, Leon Timmermans <fawaka@gmail.com> wrote:
>> >> We can stop people from saying unkind things, but how are we going to >> prevent repeats of this utter fuck-up, given that this "process" could have >> only resulted in a fuck-up? >> >> Are we going to politely destroy perl >> ?
There is no major bleep-up as yet. If we were to put our fingers in our ears and continue to turn the crank on the release process until the 5.28 release without addressing any of the problems that have been raised, then yes, that would be bad. But so far there's barely enough drama to create a sense of nostalgia for those of us who remember when "blead" meant something close enough to the razor's edge that you could cut yourself on it and all the contentious changes landed simultaneously at the worst possible time. Difficulties abound, blead is not in a releasable state, and time is short. It's a bit more like the bad old days than it should be. So we have to figure out what to do, but I'm not convinced the sky is falling or that this unique situation merits an overhaul of the way we do things generally. Show quoted text
> To expand on these points a bit, I think the process failures we had here > include: > > > - introduction of a breaking change in syntax late in the development cycle > (the cutoff for contentious changes is in less than a month, which gives > little time to resolve breakage downstream - so at this point in the cycle > such breakage should be *small* and *contained*) > > - changes were not apparently pushed to a smoke-me branch first, where we > could have assessed the amount of downstream breakage and then discussed > what to do next > (I would suggest that syntax changes *must always* be smoked first before > merging to blead)
Maybe syntax changes should come with transition advice as well, i.e., how to support Perl 5.N and 5.N+1 at the same time. Show quoted text
> - changes were not committed in a rebased branch, which (as previously > discussed) makes bisections more difficult, and also complicates the > now-inevitable reversion process > > - introduction of user-facing syntax changes to a > well-known-to-be-controversial feature without discussion of the proposal in > the greater community (outside of just p5p) of the new keywords and their > function > > > These are all things we should improve in our process. > > > respectfully, > Karen Etheridge
Good summary. I would just point out that as far as I know, a smoke-me branch doesn't automatically trigger any downstream testing. It takes a lot of cycles (people and computer) to do both the smoke testing and the BBC reports and I'm skeptical whether the downstream part will ever happen consistently and thoroughly for any branch except blead. Even the core smoke testing has pretty limited coverage of platforms, branches, and configurations. Which is just to say that I'm not sure how much of what broke with dumb_match was anticipated or could have been anticipated without merging it. In any case, now we know.
From: Kent Fredric <kentfredric [...] gmail.com>
Date: Fri, 29 Dec 2017 21:01:23 +1300
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Leon Timmermans <fawaka [...] gmail.com>, Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Aaron Crane <arc [...] cpan.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Dan Book <grinnz [...] gmail.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 792b
On 29 December 2017 at 09:28, Dan Book <grinnz@gmail.com> wrote: Show quoted text
> That's a nice start for your personal favorite aspect, but doesn't encompass > 1/10th of what such 'policies' need to cover.
For many many people, Perl's historical stability and ubiquity is the only remaining redeeming reasons for choosing it for a project. You change that, those people will simply migrate their code away from Perl. This is already a common discussion, that we release a Major Perl release, and people have the conversation of "Gosh, this broke something important AGAIN?, how about we rewrite it in python/ruby". When that happens, Perl loses. And the irony is the delusion is that by introducing these changes, we'll attract *more* projects. -- Kent KENTNL - https://metacpan.org/author/KENTNL
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Perl5 Porters <perl5-porters [...] perl.org>
To: Aaron Crane <arc [...] cpan.org>
Date: Fri, 29 Dec 2017 10:06:31 +0100
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 6.3k
Show quoted text
>>>>> On Thu, 28 Dec 2017 12:46:59 +0000, Aaron Crane <arc@cpan.org> said:
Show quoted text
> Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
>> 5. A moderation system like on p5p where a single person can define that >> certain phrases shall be punished with a life-long ban, is not one of >> the better ones. >> >> 6. The incriminated posting was already rejected by yourself and several >> others and Sawyer had answered in sovereignty (at least did I >> perceive it as such) and there was already a chance that the >> discourse could go on. No need for moderation at all. >> >> 7. We have to deal with a highly problematic blead branch with an >> unprecendented level of breakage. I find it double problematic when >> moderation kicks in while we have a huge mess to deal with anyway.
Show quoted text
> Thank you for clarifying your position, Andreas, and for subsequently > accepting a correction about the nature of the bans that moderators > can impose.
You're welcome! Show quoted text
> I'm not seeking to continue "fighting over" this matter (as your > subsequent message puts it), but I've spent the last day thinking hard > about it, and you level some specific criticisms that I'd like to > respond to. There are also some aspects of my views on the wider topic > of moderation that I think it would be helpful for me to set out > clearly.
Thank you for the effort. Show quoted text
> First and foremost, I stand by my reading of Peter's comments as > uncivil and unacceptable, and by my decision to respond as moderator > with a formal warning, in accordance with our standards of conduct.
Show quoted text
> You describe our moderation system as one "where a single person can > define that certain phrases shall be punished", and I read this > description as a specific characterisation of my actions as moderator > in this matter. I reject any contention that Peter's message required > close textual analysis of individual phrases to reach a conclusion > that it was uncivil; the entire tenor of it was fundamentally a > personal attack.
Show quoted text
> Your point 6 seems to be suggesting that, if any moderator replies to > any message as an individual, rather than ex officio as moderator, > that should automatically cause the message to be treated as > acceptable.
No, this was not what I meant. What I meant was that there was some level of rejection by several people and that this should be taken into account, no matter whether a moderator was involved or not. I'd say in this case Ricardo would not even count as a moderator because he did not state that he was (and I did not even know that he was). Show quoted text
> I disagree strongly with that: one of the reasons we have > a panel of moderators is so that no one person has to take > responsibility for doing all the unpleasant work of moderation. In the > specific case that you raise of Sawyer replying, I note also that > there is a conflict of interest if someone bearing the brunt of a > personal attack can also respond to that attack as a moderator.
When I go back and see the thread evolving, there were, according to my newsreader, already 5 answers before moderation kicked in: [24-Dec Peter Rabbitson ] Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45 [25-Dec Karl Williamson ] [25-Dec Tomasz Konojacki ] [25-Dec Ricardo Signes ] [25-Dec Sawyer X ] [25-Dec Dave Mitchell ] [27-Dec Aaron Crane ] My critique was that calmness had already been achieved without moderation. Please note also that in my time zone there was no posting on 26th in this subthread, so the subthread was calm for more than 24 hours. And the incriminated posting was already about 62 hours old. I think all these surrounding circumstances should be taken into account. Show quoted text
> You continue by saying that "there was already a chance that the > discourse could go on". This suggests you consider that the motivation > for having standards of conduct is merely to allow debate to continue > somehow.
Quite so. Show quoted text
> A consequence of that position is that, as long as *some* > debate continues, abusive and hurtful behaviour could or even should > be permitted to go unchecked.
Not necessarily. That's why I said, "please learn to look away when you are not needed". Implicit in that sentence, I would argue, is also: please continue to look whether you are needed. Show quoted text
> Again, I disagree fervently. I consider behaviour of this sort to be > unconditionally unacceptable, regardless of who displays it, the > context of the discussion, and whether any other debate continues.
This is the point where we disagree. I want to have acknowledged that people are different in their passion, their way to express their itches and their ability to tie into the loose ends in ongoing discussions, and many other aspects of communication. When a subgroup in a community is able to deal with their dissonances, moderation can probably stay out of the way. Finding the right measure then needs to be a matter of intuition. I mean "intuition" as opposed to your words "unconditionally unacceptable". Show quoted text
> The more general views I want to set out hinge on the reasons why we > have standards of conduct, and moderators who attempt to ensure > they're adhered to.
And I'm really very greatful for that, thank you! Show quoted text
> We hold ourselves to standards of conduct that allow us all to come to > the best solutions we can, in an environment of mutual respect and > assistance. This is especially true of problems without a single > obvious right answer, and where a wide variety of options and > perspectives are supported by experienced, passionate proponents.
Show quoted text
> We hold ourselves to standards of conduct that allow us to contribute > to the consideration of difficult problems without having to worry > about whether we're going to bear the brunt of an unpleasant outburst.
Show quoted text
> We hold ourselves to these standards of conduct partly to make it > clear to people who are not (yet) active members of our community > that, should they choose to take part, they will be welcomed and > respected, and that they can expect to do so without having to absorb > or defend themselves against hurtful comments — because *all* those > who take part are defended by the structures and institutions we have > put in place for that purpose.
No objection, Your Honor! Thanks, -- andreas
CC: perl5-porters [...] perl.org
Date: Fri, 29 Dec 2017 12:47:22 +0000
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 592b
In private discussion, Sawyer has explained to me that he has made a definite decision for smartmatch behaviour to be reverted for 5.28. I have reverted it in commit 7896dde7482a2851e73f0ac2c32d1c71f6e97dca. In accordance with our discussion, the core behaviour is reverted entirely, but the customised CPAN distros remain customised in order to be future-proof. It remains to be determined whether, and to what extent, smartmatch and switch features should be deprecated in 5.28. At present they are not classed as deprecated, though of course they remain marked as experimental. -zefram
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
To: Zefram <zefram [...] fysh.org>
CC: Perl5 Porters <perl5-porters [...] perl.org>
Date: Fri, 29 Dec 2017 13:52:16 +0100
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 473b
On Fri, Dec 29, 2017 at 1:47 PM, Zefram <zefram@fysh.org> wrote:
Show quoted text
In private discussion, Sawyer has explained to me that he has made a
definite decision for smartmatch behaviour to be reverted for 5.28.
I have reverted it in commit 7896dde7482a2851e73f0ac2c32d1c71f6e97dca.
In accordance with our discussion, the core behaviour is reverted
entirely, but the customised CPAN distros remain customised in order to
be future-proof.

Thank you (both of you)

Leon
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Zefram <zefram [...] fysh.org>
To: Perl5 Porters <perl5-porters [...] perl.org>
Date: Fri, 29 Dec 2017 13:45:04 +0000
Download (untitled) / with headers
text/plain 2.8k
Karen Etheridge wrote: Show quoted text
>- introduction of a breaking change in syntax late in the development cycle >(the cutoff for contentious changes is in less than a month,
A contentious change was made before the contentious-changes freeze date. It was made now rather than two months hence specifically because of the advertised freeze date. Seems like a success of process to me. If this part of the development cycle is too late to make a contentious change, then that's an argument for an earlier freeze date. Making the existing freeze date meaningless isn't the way forward. Show quoted text
>- changes were not apparently pushed to a smoke-me branch first, where we >could have assessed the amount of downstream breakage
smoke-me branches don't do that. smoke-me branches get smoked across multiple platforms, which is useful to find platform-specific problems. That's not the issue here. The kind of assessment desired here requires the changes to be published on a branch, which they were. Nothing would be gained by making it a smoke-me branch. What was lacking was people assessing the branch. Show quoted text
> (I would suggest that syntax changes *must always* be smoked first before >merging to blead)
What kind of `smoking' do you imagine here? Multi-platform smoking is almost never going to be useful for syntax changes. A cpan-smoke-me mechanism would have value, but the thing to change is to make that mechanism exist and be available. Mandating that it be used is neither necessary (if it's available) nor sufficient (if it's not available). Show quoted text
>- changes were not committed in a rebased branch, which (as previously >discussed) makes bisections more difficult, and also complicates the >now-inevitable reversion process
I don't see how people have the trouble they describe with merges. Afaik, git-bisect does not have a problem with merges. The reversion process, which I have recently completed, was not complicated in the slightest degree by the merging. (The reversion was derived from `git diff da4e04^!`, which is not affected by the history of the branch.) Nevertheless, I am now duly informed of the strength of objection to merges. I'll therefore make greater effort to avoid them in the future, even though the objection appears irrational to me. Show quoted text
>- introduction of user-facing syntax changes to a >well-known-to-be-controversial feature without discussion of the proposal >in the greater community
That's an interesting assessment. I was not aware of it being controversial until people started complaining after the merge. I was under the impression that it was an uncontroversial opinion that smartmatch needs to change in a manner substantially resembling what I'd implemented. I made sure to get the change in before the contentious-changes freeze date out of caution, anticipating a moderate amount of CPAN breakage and some possible controversy over details of the new behaviour. -zefram
Date: Fri, 29 Dec 2017 08:57:59 -0700
To: Zefram <zefram [...] fysh.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 882b
On 12/29/2017 06:45 AM, Zefram wrote: Show quoted text
>> - changes were not committed in a rebased branch, which (as previously >> discussed) makes bisections more difficult, and also complicates the >> now-inevitable reversion process
> I don't see how people have the trouble they describe with merges. > Afaik, git-bisect does not have a problem with merges. The reversion > process, which I have recently completed, was not complicated in the > slightest degree by the merging. (The reversion was derived from `git > diff da4e04^!`, which is not affected by the history of the branch.) > > Nevertheless, I am now duly informed of the strength of objection to > merges. I'll therefore make greater effort to avoid them in the future, > even though the objection appears irrational to me. >
Merges are not objected to; you have that wrong. The objections are to merging without rebasing.
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Zefram <zefram [...] fysh.org>
To: Perl5 Porters <perl5-porters [...] perl.org>
Date: Fri, 29 Dec 2017 16:50:19 +0000
Download (untitled) / with headers
text/plain 400b
Karl Williamson wrote: Show quoted text
>Merges are not objected to; you have that wrong.
Sorry, I spoke imprecisely. I am aware that the objection is specifically to non-trivial merges, i.e., to merge commits whose tree is not identical to the tree of any parent commit. My comments there about the trouble allegedly caused by merging are really about the trouble allegedly caused by non-trivial merges. -zefram
Date: Fri, 29 Dec 2017 17:55:26 +0100
To: Zefram <zefram [...] fysh.org>
CC: Perl5 Porters <perl5-porters [...] perl.org>
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 4.9k
Show quoted text
>>>>> On Fri, 29 Dec 2017 13:45:04 +0000, Zefram <zefram@fysh.org> said:
Show quoted text
> Karen Etheridge wrote:
>> - introduction of a breaking change in syntax late in the development cycle >> (the cutoff for contentious changes is in less than a month,
Show quoted text
> A contentious change was made before the contentious-changes freeze date. > It was made now rather than two months hence specifically because of the > advertised freeze date. Seems like a success of process to me. If this > part of the development cycle is too late to make a contentious change, > then that's an argument for an earlier freeze date. Making the existing > freeze date meaningless isn't the way forward.
I think we always tried to do the most contentious changes in the early days of a release cycle. Show quoted text
>> - changes were not apparently pushed to a smoke-me branch first, where we >> could have assessed the amount of downstream breakage
Show quoted text
> smoke-me branches don't do that. smoke-me branches get smoked across > multiple platforms, which is useful to find platform-specific problems. > That's not the issue here. The kind of assessment desired here requires > the changes to be published on a branch, which they were. Nothing would > be gained by making it a smoke-me branch. What was lacking was people > assessing the branch.
The problem to be warnocked have other branches too. I think it's a promotion problem, not a workflow problem, so in the end a communication gap. Show quoted text
>> (I would suggest that syntax changes *must always* be smoked first before >> merging to blead)
Show quoted text
> What kind of `smoking' do you imagine here? Multi-platform smoking is > almost never going to be useful for syntax changes. A cpan-smoke-me > mechanism would have value, but the thing to change is to make that > mechanism exist and be available. Mandating that it be used is neither > necessary (if it's available) nor sufficient (if it's not > available).
You could have asked me to do some preliminary smoking. My capacities are limited, so I cannot offer this for an arbitrary amount of branches, but I could run a smoker against a branch of interest for a few hours or days occasionally. But in this case grep.cpan.me would have been sufficient. You most probably knew you would blow every CPAN distro that used given/when, so what was needed was not a smoke but a certain amount of research and communication. Show quoted text
>> - changes were not committed in a rebased branch, which (as previously >> discussed) makes bisections more difficult, and also complicates the >> now-inevitable reversion process
Show quoted text
> I don't see how people have the trouble they describe with merges. > Afaik, git-bisect does not have a problem with merges. The reversion > process, which I have recently completed, was not complicated in the > slightest degree by the merging. (The reversion was derived from `git > diff da4e04^!`, which is not affected by the history of the branch.)
We simply trust, that what the perlgit manpage describes as the process, is followed by all parties. This process has the property that 'git describe' can be used to help humans estimate where in the monthly cycle a certain commit is situated. When 'git describe' says v5.27.5-7-g940ab75c35, it is the seventh commit after the tag and when it says v5.27.5-432-g1a98acd9b1, then you can estimate in a typical month we are quite close to the next monthly release. Simple, convenient, efficient, well established. Not so with unrebased merges. In the v5.27.6 cycle we have both a v5.27.6-50-gd6374f3d79 and a v5.27.6-50-gf60f61fd47. No question that this can be handled by git, but not so easily by humans. And let me remind you that your argument was "it would have been terribly time-consuming to rebase correctly". So the effect was shifting work around. Show quoted text
> Nevertheless, I am now duly informed of the strength of objection to > merges. I'll therefore make greater effort to avoid them in the future, > even though the objection appears irrational to me.
Key is reliability. Everything is fair if you declare your thoughts beforehand. I'm sure everybody could rewrite their scripts to deal with unrebased merges. But there was no communication about the intended change. Show quoted text
>> - introduction of user-facing syntax changes to a >> well-known-to-be-controversial feature without discussion of the proposal >> in the greater community
Show quoted text
> That's an interesting assessment. I was not aware of it being > controversial until people started complaining after the merge. > I was under the impression that it was an uncontroversial opinion > that smartmatch needs to change in a manner substantially resembling > what I'd implemented. I made sure to get the change in before the > contentious-changes freeze date out of caution, anticipating a moderate > amount of CPAN breakage and some possible controversy over details of > the new behaviour.
I'm glad Leon started the language-design-process-initiative today, such a group would hopefully prevent this sort of expectation mismatch in the future. Thanks, -- andreas
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 557b
On Fri, 29 Dec 2017 05:45:45 -0800, zefram@fysh.org wrote: Show quoted text
> Nevertheless, I am now duly informed of the strength of objection to > merges. I'll therefore make greater effort to avoid them in the future, > even though the objection appears irrational to me.
Let me explain the rationale: Not everybody has the time or the inclination to learn git that thoroughly. For many of us it’s just a tool we put up with when we have to, not a lifestyle. (That last sentence is imprecise. Please don’t waste time picking it apart.) -- Father Chrysostomos
To: Perl5 Porters <perl5-porters [...] perl.org>
Date: Fri, 29 Dec 2017 17:30:24 +0000
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Andreas Koenig wrote: Show quoted text
>We simply trust, that what the perlgit manpage describes as the process, >is followed by all parties.
perlgit doesn't describe rebasing merges as mandatory. It requests that it be done, which appears to leave room for discretion and the balancing of this request against competing concerns. perlgit needs to use stronger terms if it is to accurately reflect the strength of the objection to non-trivial merges. But apparently there isn't a total ban, because Porting/release_managers_guide.pod actually instructs the release manager to create a branch for releasing and to perform a merge that in the general case will be non-trivial (though it often happens to be trivial). Show quoted text
>And let me remind you that your argument was "it would have been >terribly time-consuming to rebase correctly". So the effect was shifting >work around.
No, it's not just shifting work around. There's a difference, large in this case, in the amount of work. I balanced the large amount of work against the slightly more complicated history. -zefram
To: Zefram <zefram [...] fysh.org>, Perl5 Porters <perl5-porters [...] perl.org>
Date: Fri, 29 Dec 2017 11:01:48 -0700
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 2.5k
On 12/29/2017 10:30 AM, Zefram wrote: Show quoted text
> Andreas Koenig wrote:
>> We simply trust, that what the perlgit manpage describes as the process, >> is followed by all parties.
> > perlgit doesn't describe rebasing merges as mandatory. It requests > that it be done, which appears to leave room for discretion and the > balancing of this request against competing concerns. perlgit needs to > use stronger terms if it is to accurately reflect the strength of the > objection to non-trivial merges. But apparently there isn't a total > ban, because Porting/release_managers_guide.pod actually instructs the > release manager to create a branch for releasing and to perform a merge > that in the general case will be non-trivial (though it often happens > to be trivial). >
>> And let me remind you that your argument was "it would have been >> terribly time-consuming to rebase correctly". So the effect was shifting >> work around.
> > No, it's not just shifting work around. There's a difference, large in > this case, in the amount of work. I balanced the large amount of work > against the slightly more complicated history. > > -zefram >
You are ignorant of all the uses that people use the history for; hence your balancing calculations were wrong. I for example, look at the delta of the history since the last time I checked (like the previous day). I do this to learn, but more importantly to look for glitches in things that I have significant expertise in, such as EBCDIC. I know that others look as well, for whatever reasons. That unrebased merge commit showed up solely as an empty diff. To see the real changes, I would have had to dig back in the log, trying to avoid the other commits I had already seen. Since smartmatch is something I know nothing about, I chose to not bother. And maybe there is some git foo I could use that would show me just the commits of interest. But there may very well be other uses that I and you are both ignorant of that any git-foo would not help. I never have thought that the language in perlgit allowed any discretion; and this is the only commit I can recall that was problematic in this way. The ease you say it was to revert seems to me to argue that it would have been similarly easy to rebase. Ether says that modern gits remember past rebasing decisions, so if you keep rebasing early and often, as our docs suggest, it isn't a problem. But, I agree with sawyer that there really is no need to this rebase issue going, as long as the lesson got learned. I'm responding here, because it's not clear to me that the lesson really did get learned.
From: ilmari [...] ilmari.org (Dagfinn Ilmari Mannsåker)
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
To: perl5-porters [...] perl.org
Date: Fri, 29 Dec 2017 18:26:12 +0000
Download (untitled) / with headers
text/plain 1.1k
Zefram <zefram@fysh.org> writes: Show quoted text
> Andreas Koenig wrote: >
>>And let me remind you that your argument was "it would have been >>terribly time-consuming to rebase correctly". So the effect was shifting >>work around.
> > No, it's not just shifting work around. There's a difference, large in > this case, in the amount of work. I balanced the large amount of work > against the slightly more complicated history.
While the discussion about reverting the merge was ongoing, I tried rebasing the branch onto the commit before the merge myself, and it was not a large amount of work. There were only a handful of conflicts that couldn't be resolved by resolved by running 'make regen', and they were pretty easy to resolve too. If you haven't already, I highly recommend enabling git's 'rerere' (reuse recorded resolution) feature by setting the rerere.enabled configuration variable. - ilmari -- - Twitter seems more influential [than blogs] in the 'gets reported in the mainstream press' sense at least. - Matt McLeod - That'd be because the content of a tweet is easier to condense down to a mainstream media article. - Calle Dybedahl
To: Perl5 Porters <perl5-porters [...] perl.org>
Date: Fri, 29 Dec 2017 18:31:37 +0000
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Zefram <zefram [...] fysh.org>
Karl Williamson wrote: Show quoted text
>The ease you say it was to revert seems to me to argue that it would have >been similarly easy to rebase.
No, they're quite different issues. Rebasing a branch with N commits requires performing textual merge work (conflict resolution, regen, testing) for each of the N commits. Merging such a branch as a non-trivial merge commit requires performing such merge work once. Reverting the change also requires performing such merge work only once, regardless of the nature of the original merge commit. Perhaps you're imagining that I would revert each commit of the dev branch separately, which would require N textual merge operations, but that again would require that N regardless of the nature of the original merge commit. Show quoted text
>But, I agree with sawyer that there really is no need to this rebase issue >going, as long as the lesson got learned.
Well, perlgit still needs to be made clearer. I'll have a go at it myself if no one else does, but I'm not at all sure of what the rule actually is, given the RMG instructions. -zefram
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
CC: Perl5 Porters <perl5-porters [...] perl.org>
To: Zefram <zefram [...] fysh.org>
Date: Fri, 29 Dec 2017 20:32:01 +0100
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 762b
On Fri, Dec 29, 2017 at 2:45 PM, Zefram <zefram@fysh.org> wrote: Show quoted text
> That's an interesting assessment. I was not aware of it being > controversial until people started complaining after the merge. > I was under the impression that it was an uncontroversial opinion > that smartmatch needs to change in a manner substantially resembling > what I'd implemented. I made sure to get the change in before the > contentious-changes freeze date out of caution, anticipating a moderate > amount of CPAN breakage and some possible controversy over details of > the new behaviour.
I think there is broad support for change, but IMO the main reason that this didn't get tackled years ago is that agreeing how it actually should work exactly is actually rather hard. Leon
From: Karen Etheridge <perl [...] froods.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>, Perl5 Porters <perl5-porters [...] perl.org>
Date: Fri, 29 Dec 2017 13:59:31 -0800
Download (untitled) / with headers
text/plain 1.1k


On Thu, Dec 28, 2017 at 8:23 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote:
Show quoted text
I would just point out that as far as I know, a
smoke-me branch doesn't automatically trigger any downstream testing.
It takes a lot of cycles (people and computer) to do both the smoke
testing and the BBC reports and I'm skeptical whether the downstream
part will ever happen consistently and thoroughly for any branch
except blead.  Even the core smoke testing has pretty limited coverage
of platforms, branches, and configurations.  Which is just to say that
I'm not sure how much of what broke with dumb_match was anticipated or
could have been anticipated without merging it.  In any case, now we
know.
Very good point; I was sloppy and conflated smoke-me branches and smoking the core tests across different​ architectures with testing against high-river cpan distributions. Do we have any process for requesting cpan testing of branches? Is it even possible to do this without a lot of manual steps? It would be fabulous if we could set up some sort of automated process for cpan testing of contentious changes, perhaps with a naming convention for branches akin to $user/smoke-me/$foo.


To: perl5-porters [...] perl.org
CC: Marc Lehmann <schmorp [...] schmorp.de>
Date: Thu, 04 Jan 2018 18:48:05 +0100
Subject: [Marc Lehmann] Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Download (untitled) / with headers
text/plain 6.4k
Hi Marc, I'm ashamed and apologize for this incident. I'm forwarding your mail to P5P and refrain from adding more words. I'll let it stand without further comments because I'm speechless. -- andreas Show quoted text
-------------------- Start of forwarded message -------------------- X-From-Line: schmorp@schmorp.de Thu Jan 4 17:52:24 2018 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on k85.linux.bogus X-Spam-Level: ****** X-Spam-Status: No, score=6.0 required=7.0 tests=BAYES_99,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Report: * 6.0 BAYES_99 BODY: Bayes spam probability is 99 to 100% * [score: 0.9990] * 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. * See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block * for more information. * [URIs: deliantra.net] Received: from rz1.akoenig.de (rz1.akoenig.de [83.223.90.65]) by k85.linux.bogus (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w04GqNQc007229 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <andreas.koenig.7os6VVqR@franz.ak.mind.de>; Thu, 4 Jan 2018 17:52:24 +0100 Received: from mail.nethype.de (mail.nethype.de [5.9.56.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by rz1.akoenig.de (Postfix) with ESMTPS id 00D9820104 for <andreas.koenig.7os6VVqR@franz.ak.mind.de>; Thu, 4 Jan 2018 17:50:50 +0100 (CET) Received: from [10.0.0.5] (helo=doom.schmorp.de) by mail.nethype.de with esmtp (Exim 4.89) (envelope-from <schmorp@schmorp.de>) id 1eX8kU-0008Tn-0p; Thu, 04 Jan 2018 16:52:10 +0000 Received: from [10.0.0.1] (helo=cerebro.laendle) by doom.schmorp.de with esmtp (Exim 4.89) (envelope-from <schmorp@schmorp.de>) id 1eX8kT-0007MC-Nz; Thu, 04 Jan 2018 16:52:09 +0000 Received: from root by cerebro.laendle with local (Exim 4.89) (envelope-from <root@schmorp.de>) id 1eX8kT-0000mY-Mx; Thu, 04 Jan 2018 17:52:09 +0100 Date: Thu, 4 Jan 2018 17:52:09 +0100 From: Marc Lehmann <schmorp@schmorp.de> To: Ricardo Signes <perl.p5p@rjbs.manxome.org>, Sawyer X <xsawyerx@gmail.com> Cc: Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>, Aaron Crane <arc@cpan.org>, Peter Rabbitson <rabbit-p5p@rabbit.us> Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45 Message-ID: <20180104165209.jyhs2a7frmklnlc6@schmorp.de> References: <20171223144437.GG19698@fysh.org> <a3c70621-51f9-d36e-882f-3b68ca85988a@gmail.com> <9de5530d-131b-5109-3e8a-03de4fabace9@rabbit.us> <CACmk_tsuGfgevBGTqTvMhWC5itEP8m_QwtHcWmgeM+3eO851=A@mail.gmail.com> <4f97e66d-8e44-3487-b802-f467b5811905@rabbit.us> <CACmk_tuT1S+kc8ywbxORbiTB_X6VnXsPF5NkTmGTRTpLvf+cUg@mail.gmail.com> <87373w8700.fsf@k85.linux.bogus> <20171227173837.GB17826@debian> <87tvwb69pk.fsf@k85.linux.bogus> <20171227234557.GA24084@debian> In-Reply-To: <20171227234557.GA24084@debian> OpenPGP: id=904ad2f81fb16978e7536f726dea2ba30bc39eb6; url=http://pgp.schmorp.de/schmorp-pgpkey.txt; preference=signencrypt X-Saved-For-King: Thu, 4 Jan 2018 17:52:56 +0100 X-Filter: mailagent [version 3.1-78] for andreas.koenig.7os6VVqR@franz.ak.mind.de Lines: 71 Xref: k85.linux.bogus king-2002:118112 On Wed, Dec 27, 2017 at 06:45:57PM -0500, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> This is not really what we have at all. I think there has been one long-term > ban issued, outside the rules of the system, by me, after long and sustained > incivility. In all other cases, what you describe is not what happens.
I don't know if this is about me, but I just found out that I am clearly banned from posting, and indeed by moderator abuse not following their own policy (I just checked perlpolicy, I didn't receive any warning for the last 6 months or anything, mostly I didn't really do any postings whatsoever, so couldn't have run afoul of any ban policy, no matter how tyrannic or not...). None of my recent mails are in any mailing list archive I checked - it's a ban. For example: http://ue.tst.eu/cc99636b1f523f181bcaed8a25a0c553.txt Rules clearly are for other people only, eh? So on the one hand, you (plural) silently block people by moderator abuse ignoring your own rules. But the other hand, you publicly(!) make bold claims about other people not following your arbitrary rules _that you can't be bothered to follow yourself_. You claim rules are in place, rules are applied fairly and so on, and in secret, you just break rules as you wish. Liars. And that's the polite way to put it - the one time I received a warning and a ban you simply lied to me. In reality, there is no different between you and other forums where moderators arbitrarily ban people for whatever reason they wish. In any case, it's bad enough that you can't even be bothered to follow your own policy regarding backwards compatibility, It's much worse that you can't follow your own *ban* policy and tyrannically make up rules as you go. No, you don't even stop at publicly spreading lies about how everybody has to follow the rules, and people not following them are banned according to your great policies. So, does it feel great when you (always plural) make up your own rules and abuse your moderator powers? Does it feel great to harass people by sending them mail and inviting them to comment, knowing well enough that their replies are being censored? Does it feel cool making statements such as participation is welcome, and then just throwing away constructive and polite contributions? And then you wonder why people don't respect you? You would have to earn it first, but you do everything you can do lose it. Wow, shame on you. I am not sure you can sink any lower than that - I honestly thought that at least you believed yourself you are following perlplicy, as deluded as that may be. It's painful to learn that I am wrong. PS: please note that even if this is a technical glitch and I am only accidentally being banned and not the subject of the non-sanbctioned perma-ban this doesn't chanmge the fact that you are breaking your own rules and arbitrarily apply different rules to different people. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\
-------------------- End of forwarded message --------------------
From: Curtis Jewell <perl [...] csjewell.fastmail.us>
Subject: Re: [Marc Lehmann] Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
To: perl5-porters [...] perl.org
Date: Thu, 04 Jan 2018 15:29:46 -0700
Andreas: I know you meant well, but please review the two threads that end in these two messages: (sorry I don't have URL's for you to use, you should be able to find them with the info I've given) before being too apologetic. I can see why Sawyer X just left him banned, personally. I wouldn't want to have his job. Date: Tue, 17 Mar 2015 07:26:51 -0400 From: Ricardo Signes <perl.p5p@rjbs.manxome.org> To: Marc Lehmann <schmorp@schmorp.de> Cc: Steve Hay <steve.m.hay@googlemail.com>, "perl5-porters@perl.org" <perl5-porters@perl.org> Subject: Re: AnyEvent and Strawberry perl issue Message-ID: <20150317112651.GA3165@cancer.codesimply.com> Subject: Re: [PATCH] - fix for Coro (was Re: revert MG consting (Coro breakage) for 5.24?) To: perl5-porters@perl.org From: Sawyer X <xsawyerx@gmail.com> Message-ID: <576B8C5F.6000004@gmail.com> Date: Thu, 23 Jun 2016 09:14:39 +0200 -- Curtis Jewell csjewell@cpan.org http://csjewell.dreamwidth.org/ perl@curtisjewell.name http://www.curtisjewell.name/ "Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c
To: Curtis Jewell <perl [...] csjewell.fastmail.us>
CC: perl5-porters [...] perl.org
Date: Thu, 4 Jan 2018 23:16:33 +0000
Subject: Re: [Marc Lehmann] Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: lannings [...] gmail.com
Download (untitled) / with headers
text/plain 491b
FWIW, I thought he (mlehmann) was unnecessarily an asshole (as always).

On Thu, Jan 4, 2018 at 10:29 PM, Curtis Jewell <perl@csjewell.fastmail.us> wrote:
Show quoted text
Andreas:

I know you meant well, but please review the two threads that end in these two messages: (sorry I don't have URL's for you to use, you should be able to find them with the info I've given) before being too apologetic.

I can see why Sawyer X just left him banned, personally. I wouldn't want to have his job.
From: Kent Fredric <kentfredric [...] gmail.com>
Subject: Re: [Marc Lehmann] Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Fri, 5 Jan 2018 12:25:14 +1300
To: lannings [...] gmail.com
CC: Curtis Jewell <perl [...] csjewell.fastmail.us>, pp Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 243b
On 5 January 2018 at 12:16, <lannings@gmail.com> wrote: Show quoted text
> FWIW, I thought he (mlehmann) was unnecessarily an asshole (as always).
Please keep your toxic commentary to yourself. Thanks. -- Kent KENTNL - https://metacpan.org/author/KENTNL
CC: perl5-porters [...] perl.org
To: Curtis Jewell <perl [...] csjewell.fastmail.us>
Date: Fri, 05 Jan 2018 00:51:10 +0100
Subject: Re: [Marc Lehmann] Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Download (untitled) / with headers
text/plain 926b
Show quoted text
>>>>> On Thu, 04 Jan 2018 15:29:46 -0700, Curtis Jewell <perl@csjewell.fastmail.us> said:
Show quoted text
> Andreas: > I know you meant well, but please review the two threads that end in these two messages: (sorry I don't have URL's for you to use, you should be able to find them with the info I've given) before being too apologetic.
Show quoted text
> I can see why Sawyer X just left him banned, personally. I wouldn't want to have his job.
It is nice from you to have warm feelings for the pumpking. I also have such. But at the border of conjectural perverting of community rules, I'd ask everybody to consider what weighs how much. We have rules in our perlpolicy and such rules are binding also for pumpkings and moderators. Moderators can ban people, but somebody has to pay attention when they do so beyond their sphere of authority. It may turn out that it was not intentional. We must hear what Sawyer has to say about it. -- andreas
Date: Fri, 05 Jan 2018 00:58:24 +0100
To: lannings [...] gmail.com
CC: Curtis Jewell <perl [...] csjewell.fastmail.us>, perl5-porters [...] perl.org
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [Marc Lehmann] Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 224b
Show quoted text
>>>>> On Thu, 4 Jan 2018 23:16:33 +0000, lannings@gmail.com said:
Show quoted text
> FWIW, I thought he (mlehmann) was unnecessarily an asshole (as > always).
Dear moderators, poster is asking for moderation for himself. -- andreas
To: lannings [...] gmail.com, Curtis Jewell <perl [...] csjewell.fastmail.us>
Subject: Re: [Marc Lehmann] Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Fri, 5 Jan 2018 09:44:06 +0200
CC: perl5-porters [...] perl.org
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 841b
This is still under discussion internally between the moderators and will be announced when resolved. Meanwhile, I request that you refrain by any offensive and hurtful comments. We can - and should - keep this professional. On 01/05/2018 01:16 AM, lannings@gmail.com wrote: Show quoted text
> FWIW, I thought he (mlehmann) was unnecessarily an asshole (as always). > > On Thu, Jan 4, 2018 at 10:29 PM, Curtis Jewell > <perl@csjewell.fastmail.us <mailto:perl@csjewell.fastmail.us>> wrote: > > Andreas: > > I know you meant well, but please review the two threads that end > in these two messages: (sorry I don't have URL's for you to use, > you should be able to find them with the info I've given) before > being too apologetic. > > I can see why Sawyer X just left him banned, personally. I > wouldn't want to have his job. >
To: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Re: [Marc Lehmann] Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Fri, 5 Jan 2018 11:28:32 +0100
CC: Curtis Jewell <perl [...] csjewell.fastmail.us>, perl5-porters [...] perl.org
From: lannings [...] gmail.com
Download (untitled) / with headers
text/plain 217b
On Fri, Jan 5, 2018 at 12:58 AM, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
Show quoted text
Dear moderators,

poster is asking for moderation for himself.

Very sorry and embarrassed (and unsubscribing)
To: perl5-porters [...] perl.org
Date: Fri, 5 Jan 2018 11:38:50 +0100
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 2.1k
* Sawyer X <xsawyerx@gmail.com> [2017-12-25 11:02]: Show quoted text
> I do not enjoy you picking the one sentence you want to respond to, > especially when it is the opposite of the complete point I am making. > I clarified that I think it should be reverted, but you looked for me > beginning with the counter point so you could have your opening to say > what you wanted. > > Now considering I've resolved to reverting it, what is the point > you're trying to drive? Convincing me to do what I said we should?
The selective quoting you complained about served the purpose of making his point, which he then states right up front: that your claim that smartmatch has always been experimental was a falsehood. Which it was. It seems odd that you would need to ask him what his point is when his point is right there. Stating this falsehood from your position of authority as the pumpking is a problem independently of whether you did so on purpose, and independently of the fact that you then go on to reach the “right” conclusion – much like getting the right answer on your maths test does not make up for making two mutually compensatory mistakes to get there. The concrete harm in this case follows from the fact that legal rather than engineering arguments (i.e. “we did not promise to support it”) tend to form the basis of justification for further decisions, and so effective revisionism (whether purposeful or accidental) about the facts of the legal status of features has non-theoretical consequences. Show quoted text
> Beyond this, as I've said to anyone else (and stand by), if you cannot > make your point without spewing sexist or otherwise offensive > behavior, please take it offline. Or, you know, learn to speak like an > adult.
Beware that merely adopting the outer forms of maturity won’t necessarily bestow its substance. Maturity can be cargoculted. (As can, incidentally, having a policy…) I also invite readers of my mail to consider the above quote in light of a broader understanding about what purposes the policing of speech can be made to serve – even unintentionally. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
From: demerphq <demerphq [...] gmail.com>
CC: Perl5 Porteros <perl5-porters [...] perl.org>
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Date: Mon, 8 Jan 2018 14:54:33 +0100
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Download (untitled) / with headers
text/plain 2.3k
On 5 January 2018 at 11:38, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: Show quoted text
> * Sawyer X <xsawyerx@gmail.com> [2017-12-25 11:02]:
>> I do not enjoy you picking the one sentence you want to respond to, >> especially when it is the opposite of the complete point I am making. >> I clarified that I think it should be reverted, but you looked for me >> beginning with the counter point so you could have your opening to say >> what you wanted. >> >> Now considering I've resolved to reverting it, what is the point >> you're trying to drive? Convincing me to do what I said we should?
> > The selective quoting you complained about served the purpose of making > his point, which he then states right up front: that your claim that > smartmatch has always been experimental was a falsehood. > > Which it was.
I checked the definition of "falsehood", which is in English "a lie". I think there is a big difference between "falsehood" and "an incorrect statement". Is there any example of Sawyer repeating this claim once he was corrected? If not then I think it is most inappropriate and inartful choice of word. I am ignoring the rest of your comment because in pretty much any "getting along as a group" rules calling someone a liar is a non-starter and not acceptable. People need to understand that being correct does NOT give one a right to be offensive, and that being incorrect is NOT a malicious act. Especially not when the *PumpKing* makes the mistake. Imputing malicious or hostile intent in a technical disagreement or policy disagreement should never happen, and should result in moderation. Just about every governing body has rules forbidding what is called in the western tradition "unparliamentary language". Suggesting that any member is dishonorable, including accusing them of lying is forbidden. As far as I am concerned this list needs to operate under similar traditions. I do not believe that there is a SINGLE person on this list who has an intent to deceive, or any form of malicious intent at all, and we should ALL avoid any suggestion to the contrary. So for me, accusing someone of spreading falsehoods, lying, or any other dishonorable behavior should result in the offender being given a chance to provide an honest apology, and if they fail to do so or the behavior is repetitive then the person should be banned. cheers, yves
To: Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Date: Mon, 8 Jan 2018 15:24:49 +0100
Download (untitled) / with headers
text/plain 231b
Show quoted text
> On 8 Jan 2018, at 14:54, demerphq <demerphq@gmail.com> wrote: > I checked the definition of "falsehood", which is in English "a lie”.
In my dictionary, a “falsehood” is "a state of being untrue”, no intent implied. Liz
From: demerphq <demerphq [...] gmail.com>
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Date: Mon, 8 Jan 2018 15:56:24 +0100
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
To: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Download (untitled) / with headers
text/plain 3.3k
On 8 January 2018 at 15:24, Elizabeth Mattijsen <liz@dijkmat.nl> wrote: Show quoted text
>> On 8 Jan 2018, at 14:54, demerphq <demerphq@gmail.com> wrote: >> I checked the definition of "falsehood", which is in English "a lie”.
> > In my dictionary, a “falsehood” is "a state of being untrue”, no intent implied.
As far as English goes "falsehood" is not the same thing as "untruth". Just about every dictionary I checked listed "a lie" higher than "an incorrect statement", or did not mention the latter at all. Virtually every reference to "falsehood" is negative. Dictionary.com: http://www.dictionary.com/browse/falsehood noun 1. a false statement; lie. Synonyms: fabrication, prevarication, falsification, canard, invention, fiction, story. 2. something false; an untrue idea, belief, etc.: The Nazis propagated the falsehood of racial superiority. 3. the act of lying or making false statements. 4. lack of conformity to truth or fact. Synonyms: untruthfulness, inveracity, mendacity. 5. Obsolete. deception. Synonym Study: 1. Falsehood, fib, lie, untruth refer to something untrue or incorrect. A falsehood is a statement that distorts or suppresses the truth, in order to deceive: to tell a falsehood about one's ancestry in order to gain acceptance. A fib denotes a trivial falsehood, and is often used to characterize that which is not strictly true: a polite fib. A lie is a vicious falsehood: to tell a lie about one's neighbor. An untruth is an incorrect statement, Try other Dictionaries as well. https://en.wiktionary.org/wiki/falsehood falsehood (countable and uncountable, plural falsehoods) (uncountable) The property of being false. quotations (countable) A false statement, especially an intentional one; a lie Don't tell falsehoods. (archaic, rare) Mendacity, deceitfulness; the trait of a person who is mendacious and deceitful. Websters: https://www.merriam-webster.com/dictionary/falsehood Definition of falsehood 1: an untrue statement : lie 2: absence of truth or accuracy 3: the practice of lying : mendacity Cambridge: https://dictionary.cambridge.org/dictionary/english/falsehood falsehood noun UK /ˈfɒls.hʊd/ US /ˈfɑːls.hʊd/ formal [ U ] lying: She doesn't seem to understand the difference between truth and falsehood. [ C ] a lie or a statement that is not correct ---------------------------------------------------------------------------------------------------------------------------------------- Even if *you* consider "falsehood" innocuous, most English speakers would not, and would consider it the imputation of dishonorable behavior, and would consider it offensive. Accusing someone of spreading falsehoods would, under any parliamentary scheme, be considered unacceptable, and the member would be required to apologize or be banished from the proceedings. I see no reason for us to behave differently personally. Notice that Aristotle used the *countable* form, which in English is always clearly interpreted as a lie. The word I think you are thinking of us "untruth" which has much lower level of association with lying and is generally considered politer. https://dictionary.cambridge.org/dictionary/english/untruth https://www.merriam-webster.com/dictionary/untruth http://www.dictionary.com/browse/untruth I couldn't find a non-pay OED to check, sorrry. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Date: Mon, 8 Jan 2018 16:31:39 +0100
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
CC: Perl5 Porteros <perl5-porters [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 3.3k
Aristotle, after some discussion on #p5p I wanted to make clear: 1. I do not think you intended to besmirch SawyersX character and therefore I do not think you should apologize for the choice of the word "falsehood". 2. To the extent that you or any others may consider my response to be overly aggressive I apologize unreservedly. 3. Of the various synonyms for "falsehood" you might choose, you may find that saying an assertion is "incorrect", "mistaken" or possibly an "untruth", as opposed to a "falsehood" is much less likely to cause someone (like me) to assume you mean "lying". 4. To a certain extent I was replying to you because I thought it was a useful forum to express my view, without getting involved in more politically sensitive side-discussions. I apologise if you consider this inappropriate. 5. No disrespect was intended to you. Sorry if any was taken. Regards, Yves On 8 January 2018 at 14:54, demerphq <demerphq@gmail.com> wrote: Show quoted text
> On 5 January 2018 at 11:38, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
>> * Sawyer X <xsawyerx@gmail.com> [2017-12-25 11:02]:
>>> I do not enjoy you picking the one sentence you want to respond to, >>> especially when it is the opposite of the complete point I am making. >>> I clarified that I think it should be reverted, but you looked for me >>> beginning with the counter point so you could have your opening to say >>> what you wanted. >>> >>> Now considering I've resolved to reverting it, what is the point >>> you're trying to drive? Convincing me to do what I said we should?
>> >> The selective quoting you complained about served the purpose of making >> his point, which he then states right up front: that your claim that >> smartmatch has always been experimental was a falsehood. >> >> Which it was.
> > I checked the definition of "falsehood", which is in English "a lie". > > I think there is a big difference between "falsehood" and "an > incorrect statement". > > Is there any example of Sawyer repeating this claim once he was > corrected? If not then I think it is most inappropriate and inartful > choice of word. > > I am ignoring the rest of your comment because in pretty much any > "getting along as a group" rules calling someone a liar is a > non-starter and not acceptable. > > People need to understand that being correct does NOT give one a right > to be offensive, and that being incorrect is NOT a malicious act. > Especially not when the *PumpKing* makes the mistake. > > Imputing malicious or hostile intent in a technical disagreement or > policy disagreement should never happen, and should result in > moderation. > > Just about every governing body has rules forbidding what is called in > the western tradition "unparliamentary language". Suggesting that any > member is dishonorable, including accusing them of lying is forbidden. > As far as I am concerned this list needs to operate under similar > traditions. > > I do not believe that there is a SINGLE person on this list who has > an intent to deceive, or any form of malicious intent at all, and we > should ALL avoid any suggestion to the contrary. > > So for me, accusing someone of spreading falsehoods, lying, or any > other dishonorable behavior should result in the offender being given > a chance to provide an honest apology, and if they fail to do so or > the behavior is repetitive then the person should be banned. > > cheers, > yves
-- perl -Mre=debug -e "/just|another|perl|hacker/"
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
Date: Thu, 19 Apr 2018 23:44:03 +0100
To: Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 459b
[snip enormous thread about changes to smartmatch which broke CPAN, which then veered off into arguments about moderation etc] IIUC, the changes to smartmatch were reverted, so this ticket can be both removed from the 5.28 blockers and closed? -- A major Starfleet emergency breaks out near the Enterprise, but fortunately some other ships in the area are able to deal with it to everyone's satisfaction. -- Things That Never Happen in "Star Trek" #13
RT-Send-CC: perl5-porters [...] perl.org
Yes — thanks for pointing that out, Dave. I'm marking this ticket resolved. -- Aaron Crane
Date: Fri, 20 Apr 2018 13:03:29 +0200
Subject: Re: [perl #132594] BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45
From: Sawyer X <xsawyerx [...] gmail.com>
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 316b
On 04/20/2018 12:44 AM, Dave Mitchell wrote: Show quoted text
> [snip enormous thread about changes to smartmatch which broke CPAN, > which then veered off into arguments about moderation etc] > > IIUC, the changes to smartmatch were reverted, so this ticket > can be both removed from the 5.28 blockers and closed?
I believe so.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org