Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45 #16310

Closed
p5pRT opened this issue Dec 17, 2017 · 84 comments
Closed

BBC smartmatch da4e040f42421764ef069371d77c008e6b801f45 #16310

p5pRT opened this issue Dec 17, 2017 · 84 comments
Labels
BBC type-core

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Dec 17, 2017

Migrated from rt.perl.org#132594 (status was 'resolved')

Searchable as RT132594$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 17, 2017

From zefram@fysh.org

Created by zefram@fysh.org

The smartmatch changes merged in commit
da4e040 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].

Perl Info

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 17, 2017

From @andk

Also affected​: ETHER/Try-Tiny-0.28.tar.gz

--
andreas

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 17, 2017

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 19, 2017

From @andk

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 20, 2017

From @andk

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 20, 2017

From @Leont

On Sun, Dec 17, 2017 at 12​:35 PM, Zefram <perlbug-followup@​perl.org> wrote​:

The smartmatch changes merged in commit
da4e040 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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 22, 2017

From @andk

Also affected, found by Slaven​:

  DBAURAIN/Bio-MUST-Drivers-0.173510.tar.gz

--
andreas

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 23, 2017

From @andk

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 23, 2017

From @eserte

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 23, 2017

From @Leont

On Sat, Dec 23, 2017 at 10​:45 AM, Slaven Rezic <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.

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 23, 2017

From @jkeenan

On 12/23/2017 07​:39 AM, Leon Timmermans wrote​:

On Sat, Dec 23, 2017 at 10​:45 AM, Slaven Rezic <slaven@​rezic.de
<mailto​:slaven@​rezic.de>> wrote​:

Also affected&#8203;:

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 23, 2017

From zefram@fysh.org

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 24, 2017

From @andk

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 24, 2017

From @xsawyerx

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​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 24, 2017

From @khwilliamson

On 12/24/2017 10​:43 AM, Sawyer X wrote​:

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 24, 2017

From @jkeenan

On 12/24/2017 12​:43 PM, Sawyer X wrote​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 24, 2017

From @ribasushi

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 25, 2017

From @khwilliamson

On 12/24/2017 02​:49 PM, Peter Rabbitson wrote​:

Please grow a pair and resign

-1

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 25, 2017

From @xenu

On Sun, 24 Dec 2017 22​:49​:34 +0100
Peter Rabbitson <rabbit-p5p@​rabbit.us> wrote​:

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 25, 2017

From @rjbs

* Peter Rabbitson <rabbit-p5p@​rabbit.us> [2017-12-24T16​:49​:34]

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 25, 2017

From zefram@fysh.org

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.

-zefram

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 25, 2017

From @xsawyerx

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​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 25, 2017

From @xsawyerx

On 12/25/2017 08​:21 AM, Zefram wrote​:

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 25, 2017

From @Leont

On Mon, Dec 25, 2017 at 7​:21 AM, Zefram <zefram@​fysh.org> wrote​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 25, 2017

From @iabyn

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.

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 27, 2017

From @arc

Sawyer X <xsawyerx@​gmail.com> wrote​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 27, 2017

From @arc

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

[1] https://metacpan.org/pod/distribution/perl/pod/perlpolicy.pod#STANDARDS-OF-CONDUCT

--
Aaron Crane

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 27, 2017

From @ribasushi

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.

Cheers

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 27, 2017

From @arc

Peter Rabbitson <rabbit-p5p@​rabbit.us> wrote​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 27, 2017

From @andk

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

--
andreas

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 29, 2017

From @andk

On Fri, 29 Dec 2017 13​:45​:04 +0000, Zefram <zefram@​fysh.org> said​:

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

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

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

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.

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

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.

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

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.

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

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 29, 2017

From @cpansprout

On Fri, 29 Dec 2017 05​:45​:45 -0800, zefram@​fysh.org wrote​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 29, 2017

From zefram@fysh.org

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 29, 2017

From @khwilliamson

On 12/29/2017 10​:30 AM, Zefram wrote​:

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 29, 2017

From @ilmari

Zefram <zefram@​fysh.org> writes​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 29, 2017

From zefram@fysh.org

Karl Williamson wrote​:

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.

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 29, 2017

From @Leont

On Fri, Dec 29, 2017 at 2​:45 PM, Zefram <zefram@​fysh.org> wrote​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 29, 2017

From @karenetheridge

On Thu, Dec 28, 2017 at 8​:23 PM, Craig A. Berry <craig.a.berry@​gmail.com>
wrote​:

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 4, 2018

From @andk

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 4, 2018

From @csjewell

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 4, 2018

From lannings@gmail.com

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​:

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 4, 2018

From @kentfredric

On 5 January 2018 at 12​:16, <lannings@​gmail.com> wrote​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 4, 2018

From @andk

On Thu, 04 Jan 2018 15​:29​:46 -0700, Curtis Jewell <perl@​csjewell.fastmail.us> said​:

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 4, 2018

From @andk

On Thu, 4 Jan 2018 23​:16​:33 +0000, lannings@​gmail.com said​:

  > FWIW, I thought he (mlehmann) was unnecessarily an asshole (as
  > always).

Dear moderators,

poster is asking for moderation for himself.

--
andreas

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 5, 2018

From @xsawyerx

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​:

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&#8203;:

I know you meant well\, but please review the two threads that end
in these two messages&#8203;: \(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\.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 5, 2018

From lannings@gmail.com

On Fri, Jan 5, 2018 at 12​:58 AM, Andreas Koenig <
andreas.koenig.7os6VVqR@​franz.ak.mind.de> wrote​:

Dear moderators,

poster is asking for moderation for himself.

Very sorry and embarrassed (and unsubscribing)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 5, 2018

From @ap

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

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.

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 8, 2018

From @demerphq

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 8, 2018

From @lizmat

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 8, 2018

From @demerphq

On 8 January 2018 at 15​:24, Elizabeth Mattijsen <liz@​dijkmat.nl> wrote​:

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/"

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 8, 2018

From @demerphq

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​:

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/"

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 19, 2018

From @iabyn

[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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 20, 2018

From @arc

Yes — thanks for pointing that out, Dave. I'm marking this ticket resolved.

--
Aaron Crane

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 20, 2018

@arc - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this as completed Apr 20, 2018
@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 20, 2018

From @xsawyerx

On 04/20/2018 12​:44 AM, Dave Mitchell wrote​:

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

@p5pRT p5pRT added BBC Severity Medium type-core labels Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BBC type-core
Projects
None yet
Development

No branches or pull requests

1 participant