Revert "Unescaped left brace in regex" fatality

[p5pRT]

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

Searchable as RT130497$

[p5pRT]

From @andk

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​:

  > On 12/08/2016 01​:08 PM\, Sawyer X wrote​:

On 12/08/2016 06​:56 PM\, Karl Williamson wrote​:

My expectation was that we would revert at the last moment before shipping 5.26.

Is it still your expectation?

  > Yes

I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle.

-- Perlin' not only for Berlin;)

perl -V

---

Summary of my perl5 (revision 5 version 25 subversion 9) configuration​:   Commit id​: 66b092637d94a05d3e747623f03f2bfc0679dcb5   Platform​:   osname=linux   osvers=4.8.0-2-amd64   archname=x86_64-linux   uname='linux k93msid 4.8.0-2-amd64 #1 smp debian 4.8.11-1 (2016-12-02) x86_64 gnulinux '   config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.25.8-146-g66b092637d/89ad -Dmyhostname=k93msid -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Dlibswanted=cl pthread socket inet nsl gdbm dbm malloc dl ld sun m crypt sec util c cposix posix ucb BSD gdbm_compat -Uuseithreads -Uuselongdouble -DDEBUGGING=-g'   hint=recommended   useposix=true   d_sigaction=define   useithreads=undef   usemultiplicity=undef   use64bitint=define   use64bitall=define   uselongdouble=undef   usemymalloc=n   bincompat5005=undef   Compiler​:   cc='cc'   ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'   optimize='-O2 -g'   cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'   ccversion=''   gccversion='6.2.1 20161124'   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/6/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 -ldl -lm -lcrypt -lutil -lc   perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc   libc=libc-2.24.so   so=so   useshrplib=false   libperl=libperl.a   gnulibc_version='2.24'   Dynamic Linking​:   dlsrc=dl_dlopen.xs   dlext=so   d_dlsymun=undef   ccdlflags='-Wl\,-E'   cccdlflags='-fPIC'   lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector-strong'

Characteristics of this binary (from libperl)​:   Compile-time options​:   HAS_TIMES   PERLIO_LAYERS   PERL_COPY_ON_WRITE   PERL_DONT_CREATE_GVSV   PERL_MALLOC_WRAP   PERL_OP_PARENT   PERL_PRESERVE_IVUV   PERL_USE_DEVEL   USE_64_BIT_ALL   USE_64_BIT_INT   USE_LARGE_FILES   USE_LOCALE   USE_LOCALE_COLLATE   USE_LOCALE_CTYPE   USE_LOCALE_NUMERIC   USE_LOCALE_TIME   USE_PERLIO   USE_PERL_ATOF   Built under linux   Compiled at Jan 3 2017 05​:02​:36   @​INC​:   /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.25.8-146-g66b092637d/89ad/lib/site_perl/5.25.9/x86_64-linux   /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.25.8-146-g66b092637d/89ad/lib/site_perl/5.25.9   /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.25.8-146-g66b092637d/89ad/lib/5.25.9/x86_64-linux   /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.25.8-146-g66b092637d/89ad/lib/5.25.9   .

[p5pRT]

From @jkeenan

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​:

On 12/08/2016 01​:08 PM\, Sawyer X wrote​:

On 12/08/2016 06​:56 PM\, Karl Williamson wrote​:

My expectation was that we would revert at the last moment before shipping 5.26.

Is it still your expectation?

Yes

I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle.

Can you identify those distributions?

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

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

[p5pRT]

From @andk

On Tue\, 03 Jan 2017 14​:42​:41 -0800\, "James E Keenan via RT" \perlbug\-followup@​perl\.org said​:   > On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​: There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle.

  > Can you identify those distributions?

| distro | dependents | comment | |-------------------------------------------------------+------------+---------------------------| | AKIHITO/Web-API-Mock-0.01 | 0 | | | AKXLIX/Haineko-0.2.16 | 0 | | | ANDREWN/Parse-Plain-3.03 | 0 | | | APNIC/Test-WWW-Selenium-HTML-0.02 | 0 | | | ASG/Primeval-0.02 | 0 | | | BOBPP/MobaSiF-Template-0.02 | 0 | | | BPHILLIPS/CatalystX-DebugFilter-0.12 | 0 | | | BPHILLIPS/CatalystX-DebugFilter-0.13 | 0 | | | BPOSTLE/Panotools-Script-0.28 | 0 | | | BRICKER/Config-Std-0.901 | 9 | | | CASIANO/Parse-Eyapp-1.182 | 7 | | | CSA/Postgres-Handler-HTML-1 | 0 | | | DANBOO/Text-xSV-Slurp-0.22 | 0 | | | DMUEY/Text-Extract-MaketextCallPhrases-0.93 | 2 | | | DROLSKY/Pg-DatabaseManager-0.05 | 2 | | | EKAWAS/PLUTO-0.30 | 2 | | | EWILHELM/Shebangml-v0.0.1 | 1 | | | FIRMICUS/LaTeX-Decode-0.04 | 0 | | | FOOLISH/Pod-Elemental-Transformer-ExampleRunner-0.002 | 0 | | | GFUJI/Acme-Hidek-44.0 | 0 | | | HESSU/Ham-APRS-FAP-1.20 | 1 | | | HIXI/Test-Clear-0.04 | 1 | | | JENDA/Exception-Class-Nested-0.04 | 0 | | | JNOLAN/Data-Walker-1.05 | 0 | | | JSWARTZ/CHI-0.60 | 235 | testing workaround exists | | KABLAMO/Vim-Debug-0.904 | 2 | | | KAZEBURO/Plack-Middleware-Log-Minimal 0.06 | 1 | | | KURIANJA/HTML-Defang-1.04 | 1 | | | LDS/Net-ISP-Balance-1.25 | 0 | | | LDS/Net-ISP-Balance-1.25 | 0 | | | MICHAEL/Decl-0.11 | 0 | | | MJGARDNER/XML-Ant-BuildFile-0.216 | 0 | | | MOB/I22r-Translate-Microsoft-0.96 | 0 | | | MOODFARM/App-Basis-ConvertText2-0.4 | 0 | | | MOZNION/Log-Minimal-Object-0.02 | 0 | | | MOZNION/WWW-NHKProgram-API-0.03 | 0 | | | MSERGEANT/XML-Handler-HTMLWriter-2.01 | 0 | | | NALOBIN/WWW-Wappalyzer-0.16 | 0 | | | NALOBIN/WWW-Wappalyzer-0.18 | 0 | | | NANARDON/MDV-Distribconf-3.14 | 0 | | | OVID/Sub-Information-0.10 | 1 | | | PAUAMMA/Geo-PostalAddress-0.04 | 0 | | | RAPHINK/Config-KingKong-0.002 | 0 | | | RCLAMP/Module-Depends-0.16 | 10 | | | REDICAPS/Net-Douban-1.14 | 0 | | | RENTOCRON/Stash-REST-0.10 | 2 | | | RETOH/Website-1.14.01 | 0 | | | ROLAND/Schedule-Cron-1.02_3 | 3 | | | ROSSI/LaTeX-Authors-0.81 | 0 | | | RPETTETT/Ham-ADIF-1.5 | 0 | | | SHMORIMO/HTML-Template-Parser-0.1011 | 1 | | | SUNDQUIST/Google-Ads-AdWords-Client-4.11.0 | 0 | | | TEMPIRE/Mojolicious-Plugin-ConsoleLogger-0.06 | 3 | | | TIMBRODY/Text-Scigen-0.02 | 0 | | | TOBYINK/PerlX-Assert-0.904 | 59 | maybe testing workaround? | | TONVOON/SNMP-Trapinfo-1.03 | 0 | | | TSCHWAND/TeX-AutoTeX-v0.906.0 | 0 | | | TULSOFT/MRS-Client-1.0.1 | 0 | | | TVIGNAUD/MDV-Distribconf-4.02 | 0 | | | VOJ/Catmandu-Importer-MWTemplates-0.01 | 0 | | | VTI/Protocol-SocketIO-0.06 | 7 | | | XAICRON/Module-Install-TestTarget-0.19 | 0 | | | YAKEX/Devel-PatchPerl-Plugin-Cygwin-v0.0.1 | 0 | | | ZEFRAM/Time-OlsonTZ-Download-0.004 | 0 | | | ZOFFIX/App-ZofCMS-1.001006 | 1 | |

The list has been compiled manually and may have wrong positives\, duplicates\, missings\, or other inaccuracies. The list is shorter than I had thought; bummer is CHI which fails when AUTOMATED_TESTING is set. Fortunately Slaven tests a lot without this environment variable set\, so we do have some test coverage of the 235 dependents\, but I did not chase them all individually.

You get the dependents via http​://deps.cpantesters.org/depended-on-by.pl

Thanks\, -- andreas

[p5pRT]

From @jkeenan

On Wed\, 04 Jan 2017 07​:49​:51 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

On Tue\, 03 Jan 2017 14​:42​:41 -0800\, "James E Keenan via RT" \perlbug\-followup@​perl\.org said​: On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​: There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle.

Can you identify those distributions?

distro	dependents		comment		-------------------------------------------------------+------------	+---------------------------		AKIHITO/Web-API-Mock-0.01	0
AKXLIX/Haineko-0.2.16	0
ANDREWN/Parse-Plain-3.03	0
APNIC/Test-WWW-Selenium-HTML-0.02	0
ASG/Primeval-0.02	0
BOBPP/MobaSiF-Template-0.02	0
BPHILLIPS/CatalystX-DebugFilter-0.12	0
BPHILLIPS/CatalystX-DebugFilter-0.13	0
BPOSTLE/Panotools-Script-0.28	0
BRICKER/Config-Std-0.901	9
CASIANO/Parse-Eyapp-1.182	7
CSA/Postgres-Handler-HTML-1	0
DANBOO/Text-xSV-Slurp-0.22	0
DMUEY/Text-Extract-MaketextCallPhrases-0.93	2
DROLSKY/Pg-DatabaseManager-0.05	2
EKAWAS/PLUTO-0.30	2
EWILHELM/Shebangml-v0.0.1	1
FIRMICUS/LaTeX-Decode-0.04	0
FOOLISH/Pod-Elemental-Transformer-ExampleRunner-0.002	0
GFUJI/Acme-Hidek-44.0	0
HESSU/Ham-APRS-FAP-1.20	1
HIXI/Test-Clear-0.04	1
JENDA/Exception-Class-Nested-0.04	0
JNOLAN/Data-Walker-1.05	0
JSWARTZ/CHI-0.60	235
testing workaround exists
KABLAMO/Vim-Debug-0.904	2
KAZEBURO/Plack-Middleware-Log-Minimal 0.06	1
KURIANJA/HTML-Defang-1.04	1
LDS/Net-ISP-Balance-1.25	0
LDS/Net-ISP-Balance-1.25	0
MICHAEL/Decl-0.11	0
MJGARDNER/XML-Ant-BuildFile-0.216	0
MOB/I22r-Translate-Microsoft-0.96	0
MOODFARM/App-Basis-ConvertText2-0.4	0
MOZNION/Log-Minimal-Object-0.02	0
MOZNION/WWW-NHKProgram-API-0.03	0
MSERGEANT/XML-Handler-HTMLWriter-2.01	0
NALOBIN/WWW-Wappalyzer-0.16	0
NALOBIN/WWW-Wappalyzer-0.18	0
NANARDON/MDV-Distribconf-3.14	0
OVID/Sub-Information-0.10	1
PAUAMMA/Geo-PostalAddress-0.04	0
RAPHINK/Config-KingKong-0.002	0
RCLAMP/Module-Depends-0.16	10
REDICAPS/Net-Douban-1.14	0
RENTOCRON/Stash-REST-0.10	2
RETOH/Website-1.14.01	0
ROLAND/Schedule-Cron-1.02_3	3
ROSSI/LaTeX-Authors-0.81	0
RPETTETT/Ham-ADIF-1.5	0
SHMORIMO/HTML-Template-Parser-0.1011	1
SUNDQUIST/Google-Ads-AdWords-Client-4.11.0	0
TEMPIRE/Mojolicious-Plugin-ConsoleLogger-0.06	3
TIMBRODY/Text-Scigen-0.02	0
TOBYINK/PerlX-Assert-0.904	59
maybe testing workaround?
TONVOON/SNMP-Trapinfo-1.03	0
TSCHWAND/TeX-AutoTeX-v0.906.0	0
TULSOFT/MRS-Client-1.0.1	0
TVIGNAUD/MDV-Distribconf-4.02	0
VOJ/Catmandu-Importer-MWTemplates-0.01	0
VTI/Protocol-SocketIO-0.06	7
XAICRON/Module-Install-TestTarget-0.19	0
YAKEX/Devel-PatchPerl-Plugin-Cygwin-v0.0.1	0
ZEFRAM/Time-OlsonTZ-Download-0.004	0
ZOFFIX/App-ZofCMS-1.001006	1

The list has been compiled manually and may have wrong positives\, duplicates\, missings\, or other inaccuracies. The list is shorter than I had thought; bummer is CHI which fails when AUTOMATED_TESTING is set. Fortunately Slaven tests a lot without this environment variable set\, so we do have some test coverage of the 235 dependents\, but I did not chase them all individually.

You get the dependents via http​://deps.cpantesters.org/depended-on- by.pl

Thanks\,

Andreas\, thanks for providing that list.

I'm attaching a reduced version of that list holding only those distributions where the dependencies count > 0. Using cpanm\, I was able to install both CHI and PerlX-Assert at blead. That leaves 19 unpatched distributions. I suspect you've probably filed bug reports for each of these (correct me if that's wrong). Indeed\, I know that I've submitted patches for some of these.

So the questions we face are​:

* How do we get the maintainers of these 19 distros to fix the fatal-brace errors so that we can then go on to perform regular CPANtesters runs on each of their respective dependencies?

* What are the advantages/disadvantages to the Perl ecosystem if we revert\, i.e.\, if we do not proceed to fatalize the unescaped left brace in perl-5.26?

* Conversely\, what are the advantages/disadvantages to the Perl ecosystem if we do not revert\, i.e.\, we proceed as planned to fatalize in perl-5.26?

Thank you very much. -- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @jkeenan

fatal-brace-with-dependencies-20170104.psv

[p5pRT]

From @jkeenan

On Wed\, 04 Jan 2017 13​:29​:49 GMT\, jkeenan wrote​:

On Wed\, 04 Jan 2017 07​:49​:51 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

On Tue\, 03 Jan 2017 14​:42​:41 -0800\, "James E Keenan via RT" \perlbug\-followup@​perl\.org said​: On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​: There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle.

Can you identify those distributions?

distro	dependents
comment

-------------------------------------------------------+------------	+---------------------------		AKIHITO/Web-API-Mock-0.01	0
AKXLIX/Haineko-0.2.16	0
ANDREWN/Parse-Plain-3.03	0
APNIC/Test-WWW-Selenium-HTML-0.02	0
ASG/Primeval-0.02	0
BOBPP/MobaSiF-Template-0.02	0
BPHILLIPS/CatalystX-DebugFilter-0.12	0
BPHILLIPS/CatalystX-DebugFilter-0.13	0
BPOSTLE/Panotools-Script-0.28	0
BRICKER/Config-Std-0.901	9
CASIANO/Parse-Eyapp-1.182	7
CSA/Postgres-Handler-HTML-1	0
DANBOO/Text-xSV-Slurp-0.22	0
DMUEY/Text-Extract-MaketextCallPhrases-0.93	2
DROLSKY/Pg-DatabaseManager-0.05	2
EKAWAS/PLUTO-0.30	2
EWILHELM/Shebangml-v0.0.1	1
FIRMICUS/LaTeX-Decode-0.04	0
FOOLISH/Pod-Elemental-Transformer-ExampleRunner-0.002	0
GFUJI/Acme-Hidek-44.0	0
HESSU/Ham-APRS-FAP-1.20	1
HIXI/Test-Clear-0.04	1
JENDA/Exception-Class-Nested-0.04	0
JNOLAN/Data-Walker-1.05	0
JSWARTZ/CHI-0.60	235
testing workaround exists
KABLAMO/Vim-Debug-0.904	2
KAZEBURO/Plack-Middleware-Log-Minimal 0.06	1
KURIANJA/HTML-Defang-1.04	1
LDS/Net-ISP-Balance-1.25	0
LDS/Net-ISP-Balance-1.25	0
MICHAEL/Decl-0.11	0
MJGARDNER/XML-Ant-BuildFile-0.216	0
MOB/I22r-Translate-Microsoft-0.96	0
MOODFARM/App-Basis-ConvertText2-0.4	0
MOZNION/Log-Minimal-Object-0.02	0
MOZNION/WWW-NHKProgram-API-0.03	0
MSERGEANT/XML-Handler-HTMLWriter-2.01	0
NALOBIN/WWW-Wappalyzer-0.16	0
NALOBIN/WWW-Wappalyzer-0.18	0
NANARDON/MDV-Distribconf-3.14	0
OVID/Sub-Information-0.10	1
PAUAMMA/Geo-PostalAddress-0.04	0
RAPHINK/Config-KingKong-0.002	0
RCLAMP/Module-Depends-0.16	10
REDICAPS/Net-Douban-1.14	0
RENTOCRON/Stash-REST-0.10	2
RETOH/Website-1.14.01	0
ROLAND/Schedule-Cron-1.02_3	3
ROSSI/LaTeX-Authors-0.81	0
RPETTETT/Ham-ADIF-1.5	0
SHMORIMO/HTML-Template-Parser-0.1011	1
SUNDQUIST/Google-Ads-AdWords-Client-4.11.0	0
TEMPIRE/Mojolicious-Plugin-ConsoleLogger-0.06	3
TIMBRODY/Text-Scigen-0.02	0
TOBYINK/PerlX-Assert-0.904	59
maybe testing workaround?
TONVOON/SNMP-Trapinfo-1.03	0
TSCHWAND/TeX-AutoTeX-v0.906.0	0
TULSOFT/MRS-Client-1.0.1	0
TVIGNAUD/MDV-Distribconf-4.02	0
VOJ/Catmandu-Importer-MWTemplates-0.01	0
VTI/Protocol-SocketIO-0.06	7
XAICRON/Module-Install-TestTarget-0.19	0
YAKEX/Devel-PatchPerl-Plugin-Cygwin-v0.0.1	0
ZEFRAM/Time-OlsonTZ-Download-0.004	0
ZOFFIX/App-ZofCMS-1.001006	1

The list has been compiled manually and may have wrong positives\, duplicates\, missings\, or other inaccuracies. The list is shorter than I had thought; bummer is CHI which fails when AUTOMATED_TESTING is set. Fortunately Slaven tests a lot without this environment variable set\, so we do have some test coverage of the 235 dependents\, but I did not chase them all individually.

You get the dependents via http​://deps.cpantesters.org/depended-on- by.pl

Thanks\,

Andreas\, thanks for providing that list.

I'm attaching a reduced version of that list holding only those distributions where the dependencies count > 0. Using cpanm\, I was able to install both CHI and PerlX-Assert at blead. That leaves 19 unpatched distributions. I suspect you've probably filed bug reports for each of these (correct me if that's wrong). Indeed\, I know that I've submitted patches for some of these.

So the questions we face are​:

* How do we get the maintainers of these 19 distros to fix the fatal- brace errors so that we can then go on to perform regular CPANtesters runs on each of their respective dependencies?

* What are the advantages/disadvantages to the Perl ecosystem if we revert\, i.e.\, if we do not proceed to fatalize the unescaped left brace in perl-5.26?

* Conversely\, what are the advantages/disadvantages to the Perl ecosystem if we do not revert\, i.e.\, we proceed as planned to fatalize in perl-5.26?

Thank you very much.

Re-attaching file with .txt extension to make it more visible.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @jkeenan

distro|dependents|comment| BRICKER/Config-Std-0.901|9|| CASIANO/Parse-Eyapp-1.182|7|| DMUEY/Text-Extract-MaketextCallPhrases-0.93|2|| DROLSKY/Pg-DatabaseManager-0.05|2|| EKAWAS/PLUTO-0.30|2|| EWILHELM/Shebangml-v0.0.1|1|| HESSU/Ham-APRS-FAP-1.20|1|| HIXI/Test-Clear-0.04|1|| JSWARTZ/CHI-0.60|235|testingworkaroundexists| KABLAMO/Vim-Debug-0.904|2|| KAZEBURO/Plack-Middleware-Log-Minimal0.06|1|| KURIANJA/HTML-Defang-1.04|1|| OVID/Sub-Information-0.10|1|| RCLAMP/Module-Depends-0.16|10|| RENTOCRON/Stash-REST-0.10|2|| ROLAND/Schedule-Cron-1.02_3|3|| SHMORIMO/HTML-Template-Parser-0.1011|1|| TEMPIRE/Mojolicious-Plugin-ConsoleLogger-0.06|3|| TOBYINK/PerlX-Assert-0.904|59|maybetestingworkaround?| VTI/Protocol-SocketIO-0.06|7|| ZOFFIX/App-ZofCMS-1.001006|1||

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, 04 Jan 2017 13​:29​:49 GMT\, jkeenan wrote​:

On Wed\, 04 Jan 2017 07​:49​:51 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

On Tue\, 03 Jan 2017 14​:42​:41 -0800\, "James E Keenan via RT" \perlbug\-followup@​perl\.org said​: On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​: There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle.

Can you identify those distributions?

distro	dependents
comment

-------------------------------------------------------+------------	+---------------------------		AKIHITO/Web-API-Mock-0.01	0
AKXLIX/Haineko-0.2.16	0
ANDREWN/Parse-Plain-3.03	0
APNIC/Test-WWW-Selenium-HTML-0.02	0
ASG/Primeval-0.02	0
BOBPP/MobaSiF-Template-0.02	0
BPHILLIPS/CatalystX-DebugFilter-0.12	0
BPHILLIPS/CatalystX-DebugFilter-0.13	0
BPOSTLE/Panotools-Script-0.28	0
BRICKER/Config-Std-0.901	9
CASIANO/Parse-Eyapp-1.182	7
CSA/Postgres-Handler-HTML-1	0
DANBOO/Text-xSV-Slurp-0.22	0
DMUEY/Text-Extract-MaketextCallPhrases-0.93	2
DROLSKY/Pg-DatabaseManager-0.05	2
EKAWAS/PLUTO-0.30	2
EWILHELM/Shebangml-v0.0.1	1
FIRMICUS/LaTeX-Decode-0.04	0
FOOLISH/Pod-Elemental-Transformer-ExampleRunner-0.002	0
GFUJI/Acme-Hidek-44.0	0
HESSU/Ham-APRS-FAP-1.20	1
HIXI/Test-Clear-0.04	1
JENDA/Exception-Class-Nested-0.04	0
JNOLAN/Data-Walker-1.05	0
JSWARTZ/CHI-0.60	235
testing workaround exists
KABLAMO/Vim-Debug-0.904	2
KAZEBURO/Plack-Middleware-Log-Minimal 0.06	1
KURIANJA/HTML-Defang-1.04	1
LDS/Net-ISP-Balance-1.25	0
LDS/Net-ISP-Balance-1.25	0
MICHAEL/Decl-0.11	0
MJGARDNER/XML-Ant-BuildFile-0.216	0
MOB/I22r-Translate-Microsoft-0.96	0
MOODFARM/App-Basis-ConvertText2-0.4	0
MOZNION/Log-Minimal-Object-0.02	0
MOZNION/WWW-NHKProgram-API-0.03	0
MSERGEANT/XML-Handler-HTMLWriter-2.01	0
NALOBIN/WWW-Wappalyzer-0.16	0
NALOBIN/WWW-Wappalyzer-0.18	0
NANARDON/MDV-Distribconf-3.14	0
OVID/Sub-Information-0.10	1
PAUAMMA/Geo-PostalAddress-0.04	0
RAPHINK/Config-KingKong-0.002	0
RCLAMP/Module-Depends-0.16	10
REDICAPS/Net-Douban-1.14	0
RENTOCRON/Stash-REST-0.10	2
RETOH/Website-1.14.01	0
ROLAND/Schedule-Cron-1.02_3	3
ROSSI/LaTeX-Authors-0.81	0
RPETTETT/Ham-ADIF-1.5	0
SHMORIMO/HTML-Template-Parser-0.1011	1
SUNDQUIST/Google-Ads-AdWords-Client-4.11.0	0
TEMPIRE/Mojolicious-Plugin-ConsoleLogger-0.06	3
TIMBRODY/Text-Scigen-0.02	0
TOBYINK/PerlX-Assert-0.904	59
maybe testing workaround?
TONVOON/SNMP-Trapinfo-1.03	0
TSCHWAND/TeX-AutoTeX-v0.906.0	0
TULSOFT/MRS-Client-1.0.1	0
TVIGNAUD/MDV-Distribconf-4.02	0
VOJ/Catmandu-Importer-MWTemplates-0.01	0
VTI/Protocol-SocketIO-0.06	7
XAICRON/Module-Install-TestTarget-0.19	0
YAKEX/Devel-PatchPerl-Plugin-Cygwin-v0.0.1	0
ZEFRAM/Time-OlsonTZ-Download-0.004	0
ZOFFIX/App-ZofCMS-1.001006	1

The list has been compiled manually and may have wrong positives\, duplicates\, missings\, or other inaccuracies. The list is shorter than I had thought; bummer is CHI which fails when AUTOMATED_TESTING is set. Fortunately Slaven tests a lot without this environment variable set\, so we do have some test coverage of the 235 dependents\, but I did not chase them all individually.

You get the dependents via http​://deps.cpantesters.org/depended-on- by.pl

Thanks\,

Andreas\, thanks for providing that list.

I'm attaching a reduced version of that list holding only those distributions where the dependencies count > 0. Using cpanm\, I was able to install both CHI and PerlX-Assert at blead. That leaves 19 unpatched distributions. I suspect you've probably filed bug reports for each of these (correct me if that's wrong). Indeed\, I know that I've submitted patches for some of these.

So the questions we face are​:

* How do we get the maintainers of these 19 distros to fix the fatal- brace errors so that we can then go on to perform regular CPANtesters runs on each of their respective dependencies?

* What are the advantages/disadvantages to the Perl ecosystem if we revert\, i.e.\, if we do not proceed to fatalize the unescaped left brace in perl-5.26?

* Conversely\, what are the advantages/disadvantages to the Perl ecosystem if we do not revert\, i.e.\, we proceed as planned to fatalize in perl-5.26?

Thank you very much.

Re-attaching file with .txt extension to make it more visible.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @jkeenan

On Wed\, 04 Jan 2017 13​:29​:49 GMT\, jkeenan wrote​:

Andreas\, thanks for providing that list.

I'm attaching a reduced version of that list holding only those distributions where the dependencies count > 0. Using cpanm\, I was able to install both CHI and PerlX-Assert at blead. That leaves 19 unpatched distributions. I suspect you've probably filed bug reports for each of these (correct me if that's wrong). Indeed\, I know that I've submitted patches for some of these.

I can confirm that you\, Slaven or I have submitted bug reports or created github issues for each of the 19 distributions with dependencies. So we need to determine who to get those issues addressed and new CPAN releases issued in a timely manner.

Thank you very much. -- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From cpan@zoffix.com

Noticed this ticket by accident... Shipped fixed version of ZOFFIX/App-ZofCMS to CPAN

[p5pRT]

From [Unknown Contact. See original ticket]

Noticed this ticket by accident... Shipped fixed version of ZOFFIX/App-ZofCMS to CPAN

[p5pRT]

From @khwilliamson

On 1/3/2017 3​:42 PM\, James E Keenan via RT wrote​:

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​: On 12/08/2016 01​:08 PM\, Sawyer X wrote​:

On 12/08/2016 06​:56 PM\, Karl Williamson wrote​:

My expectation was that we would revert at the last moment before shipping 5.26. Is it still your expectation? Yes I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle. Can you identify those distributions?

I believe he means\, which distributions are the ones that are preventing the rest of CPAN from being tested. We believe that PRs have been issued for all distributions identified previously. If the number is small\, we could apply pressure on those few authors to get their act together. If large or they are obstinate\, we will have to revert.

Thank you very much.

[p5pRT]

From @jkeenan

On Thu\, 05 Jan 2017 14​:07​:29 GMT\, khw@​indra.com wrote​:

On 1/3/2017 3​:42 PM\, James E Keenan via RT wrote​:

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​: On 12/08/2016 01​:08 PM\, Sawyer X wrote​:

On 12/08/2016 06​:56 PM\, Karl Williamson wrote​:

My expectation was that we would revert at the last moment before shipping 5.26. Is it still your expectation? Yes I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle. Can you identify those distributions?

I believe he means\, which distributions are the ones that are preventing the rest of CPAN from being tested.

Well\, what I was actually hoping for was a list of the distributions which *have been prevented from being tested*. My premise has been that it was the distros in Andreas's list with > 0 dependencies which are doing the preventing. Was that premise incorrect?

We believe that PRs have been issued for all distributions identified previously. If the number is small\, we could apply pressure on those few authors to get their act together. If large or they are obstinate\, we will have to revert.

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @jkeenan

On Thu\, 05 Jan 2017 14​:07​:29 GMT\, khw@​indra.com wrote​:

On 1/3/2017 3​:42 PM\, James E Keenan via RT wrote​:

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​: On 12/08/2016 01​:08 PM\, Sawyer X wrote​:

On 12/08/2016 06​:56 PM\, Karl Williamson wrote​:

My expectation was that we would revert at the last moment before shipping 5.26. Is it still your expectation? Yes I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle. Can you identify those distributions?

I believe he means\, which distributions are the ones that are preventing the rest of CPAN from being tested. We believe that PRs have been issued for all distributions identified previously. If the number is small\, we could apply pressure on those few authors to get their act together.

If we go that route -- and to a certain extent I think we will have to -- here is some suggested language (attachment).

If large or they are obstinate\, we will have to revert.

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @jkeenan

This is a bug report for​:

__________

Today I attempted to build and test this distribution against Perl 5 blead* using the 'cpanm' tool. I observed the failures observed in the log file attached. In the development version of Perl 5 (perl-5.25.x)\, unescaped left braces in certain regular expression patterns have been made a fatal error. These errors are quite easy to correct and I am prepared to provide you assitance in correcting them.

I would recommend that you correct these problems at your earliest opportunity for two reasons​:

1. So that your distribution passes all tests when perl-5.26.0 is released in May of this year.

2. Other CPAN distributions depend on yours. In preparation for the release of perl-5.26.0\, CPAN testers would like to be able to test those distributions against Perl 5 blead as well. However\, they are unable to do so as long as your distribution is encountering this problem. You can see the list of other CPAN distributions which have yours as a dependency at​:

http​://deps.cpantesters.org/depended-on-by.pl?dist=__________

By correcting this problem\, you will be helping to ensure that both your distribution and those dependent on yours will continue to work on Perl in the future.

Thank you very much.

[p5pRT]

From @jkeenan

On Wed\, 04 Jan 2017 13​:34​:03 GMT\, jkeenan wrote​:

On Wed\, 04 Jan 2017 13​:29​:49 GMT\, jkeenan wrote​:

On Wed\, 04 Jan 2017 07​:49​:51 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

ZOFFIX/App-ZofCMS-1.001006	1

App-ZofCMS maintainer responded to pull request. This distro now PASS.

1 down; 18 (or 20\, depending on how you count) to go.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @xsawyerx

On 01/03/2017 11​:50 PM\, Karl Williamson wrote​:

On 1/3/2017 3​:42 PM\, James E Keenan via RT wrote​:

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​: On 12/08/2016 01​:08 PM\, Sawyer X wrote​:

On 12/08/2016 06​:56 PM\, Karl Williamson wrote​:

My expectation was that we would revert at the last moment before shipping 5.26. Is it still your expectation? Yes I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle. Can you identify those distributions?

I believe he means\, which distributions are the ones that are preventing the rest of CPAN from being tested. We believe that PRs have been issued for all distributions identified previously. If the number is small\, we could apply pressure on those few authors to get their act together. If large or they are obstinate\, we will have to revert.

We need to decide on an appropriate deadline for reverting\, in case the distributions are not fixed and released by then. Also\, what is our accepted amount of distributions to fix this?

[p5pRT]

From @xsawyerx

On 01/05/2017 04​:15 PM\, James E Keenan via RT wrote​:

On Thu\, 05 Jan 2017 14​:07​:29 GMT\, khw@​indra.com wrote​:

On 1/3/2017 3​:42 PM\, James E Keenan via RT wrote​:

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​: On 12/08/2016 01​:08 PM\, Sawyer X wrote​: On 12/08/2016 06​:56 PM\, Karl Williamson wrote​: My expectation was that we would revert at the last moment before shipping 5.26. Is it still your expectation? Yes I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle. Can you identify those distributions? I believe he means\, which distributions are the ones that are preventing the rest of CPAN from being tested. We believe that PRs have been issued for all distributions identified previously. If the number is small\, we could apply pressure on those few authors to get their act together.
If we go that route -- and to a certain extent I think we will have to -- here is some suggested language (attachment).

A more succinct version. What do you think? (Attached.)

[p5pRT]

From @xsawyerx

# This is a bug report for​:

Due to unescaped left braces in some regular expression patterns in your code\, your module won't work on 5.26.0. The CPAN Tester automated testing service cannot test your distribution on new versions of Perl until it is fixed and any modules that depend on yours will not work either.

We would appreciate help in sorting this out before the new version of Perl is released in May of this year. These errors are quite easy to correct and I would be happy to lend a hand.

I'm including a log file of my failure to build and install using "cpanm".

Here is a link to all modules that depend on yours​: http​://deps.cpantesters.org/depended-on-by.pl?dist=__________

Thanks!

[p5pRT]

From @jkeenan

On Fri\, 06 Jan 2017 09​:36​:01 GMT\, xsawyerx@​gmail.com wrote​:

On 01/05/2017 04​:15 PM\, James E Keenan via RT wrote​:

On Thu\, 05 Jan 2017 14​:07​:29 GMT\, khw@​indra.com wrote​:

On 1/3/2017 3​:42 PM\, James E Keenan via RT wrote​:

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​: On 12/08/2016 01​:08 PM\, Sawyer X wrote​: On 12/08/2016 06​:56 PM\, Karl Williamson wrote​: My expectation was that we would revert at the last moment before shipping 5.26. Is it still your expectation? Yes I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle. Can you identify those distributions? I believe he means\, which distributions are the ones that are preventing the rest of CPAN from being tested. We believe that PRs have been issued for all distributions identified previously. If the number is small\, we could apply pressure on those few authors to get their act together. If we go that route -- and to a certain extent I think we will have to -- here is some suggested language (attachment).

A more succinct version. What do you think? (Attached.)

##### "We would appreciate help in sorting this out before the new version of Perl is released in May of this year." #####

As I look at this (and similar language in my original version)\, I'm thinking this is too lenient. A maintainer reading it might think he/she has until mid-May to fix the braces and do a new CPAN release. Because this blocks the testing of other CPAN distros\, I think we should suggest a deadline​: 2 weeks after this message is added to the existing bug ticket.

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @jkeenan

On Fri\, 06 Jan 2017 09​:19​:35 GMT\, xsawyerx@​gmail.com wrote​:

On 01/03/2017 11​:50 PM\, Karl Williamson wrote​:

On 1/3/2017 3​:42 PM\, James E Keenan via RT wrote​:

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​: On 12/08/2016 01​:08 PM\, Sawyer X wrote​:

On 12/08/2016 06​:56 PM\, Karl Williamson wrote​:

My expectation was that we would revert at the last moment before shipping 5.26. Is it still your expectation? Yes I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle. Can you identify those distributions?

I believe he means\, which distributions are the ones that are preventing the rest of CPAN from being tested. We believe that PRs have been issued for all distributions identified previously. If the number is small\, we could apply pressure on those few authors to get their act together. If large or they are obstinate\, we will have to revert.

We need to decide on an appropriate deadline for reverting\, in case the distributions are not fixed and released by then. Also\, what is our accepted amount of distributions to fix this?

My recommendations stem from a desire to *not* revert the fatal-left-brace change and a willingness to consequently sustain some breakage when 5.26.0 is released. YMMV.

1. Two distros were special-cased in Andreas's list​: CHI and PerlX-Assert. Get clarification from Andreas and Slaven as to what the CPANtester-related problems and workarounds are.

2. For the other 18 distros with dependencies\, post in each existing rt.cpan.org ticket or github.com pull request a notice with a request for action within two weeks.

3. For the distros which have the problem but which\, in Andreas's list\, have 0 dependencies\, post a gentler message in the ticket/pull request reminding the maintainer of the problem. (But we won't take further action.)

4. After two weeks\, repeat post in (2) as needed. Consider possibility of notifying the maintainers of the dependent distros that CPAN testing of their distros is blocked.

5. Of the 18 remaining distros with dependencies\, 11 have N > 1 dependencies. If we get a majority -- 6 -- of those distros corrected and re-released\, then\, IMO\, we should be content with our efforts and clear this as a blocker to 5.26.0.

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @xsawyerx

This failed yesterday\, so I'm trying to resend it again today.

On 01/06/2017 02​:42 PM\, James E Keenan via RT wrote​:

On Fri\, 06 Jan 2017 09​:19​:35 GMT\, xsawyerx@​gmail.com wrote​:

On 01/03/2017 11​:50 PM\, Karl Williamson wrote​:

On 1/3/2017 3​:42 PM\, James E Keenan via RT wrote​:

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​: On 12/08/2016 01​:08 PM\, Sawyer X wrote​: On 12/08/2016 06​:56 PM\, Karl Williamson wrote​: My expectation was that we would revert at the last moment before shipping 5.26. Is it still your expectation? Yes I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle. Can you identify those distributions? I believe he means\, which distributions are the ones that are preventing the rest of CPAN from being tested. We believe that PRs have been issued for all distributions identified previously. If the number is small\, we could apply pressure on those few authors to get their act together. If large or they are obstinate\, we will have to revert. We need to decide on an appropriate deadline for reverting\, in case the distributions are not fixed and released by then. Also\, what is our accepted amount of distributions to fix this?

My recommendations stem from a desire to *not* revert the fatal-left-brace change and a willingness to consequently sustain some breakage when 5.26.0 is released. YMMV.

1. Two distros were special-cased in Andreas's list​: CHI and PerlX-Assert. Get clarification from Andreas and Slaven as to what the CPANtester-related problems and workarounds are.

2. For the other 18 distros with dependencies\, post in each existing rt.cpan.org ticket or github.com pull request a notice with a request for action within two weeks.

3. For the distros which have the problem but which\, in Andreas's list\, have 0 dependencies\, post a gentler message in the ticket/pull request reminding the maintainer of the problem. (But we won't take further action.)

4. After two weeks\, repeat post in (2) as needed. Consider possibility of notifying the maintainers of the dependent distros that CPAN testing of their distros is blocked.

5. Of the 18 remaining distros with dependencies\, 11 have N > 1 dependencies. If we get a majority -- 6 -- of those distros corrected and re-released\, then\, IMO\, we should be content with our efforts and clear this as a blocker to 5.26.0.

This sounds like a solid plan to me. Thank you for spearheading this.

[p5pRT]

From @xsawyerx

This failed yesterday\, so I'm trying it again today.

On 01/06/2017 02​:27 PM\, James E Keenan via RT wrote​:

On Fri\, 06 Jan 2017 09​:36​:01 GMT\, xsawyerx@​gmail.com wrote​:

On 01/05/2017 04​:15 PM\, James E Keenan via RT wrote​:

On Thu\, 05 Jan 2017 14​:07​:29 GMT\, khw@​indra.com wrote​:

On 1/3/2017 3​:42 PM\, James E Keenan via RT wrote​:

On Tue\, 03 Jan 2017 22​:00​:53 GMT\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139​:

On Thu\, 8 Dec 2016 13​:44​:32 -0700\, Karl Williamson \public@​khwilliamson\.com said​: On 12/08/2016 01​:08 PM\, Sawyer X wrote​: On 12/08/2016 06​:56 PM\, Karl Williamson wrote​: My expectation was that we would revert at the last moment before shipping 5.26. Is it still your expectation? Yes I would like to call up and suggest that now is the last moment before the release of 5.26.

There is a portion of the CPAN that remained untested throughout the 5.25 cycle due to this fatality​: every module that fails since the commit itself and all their dependencies. Reverting this change now will give that fraction a chance to be tested for the first time in the 5.25 cycle. Can you identify those distributions? I believe he means\, which distributions are the ones that are preventing the rest of CPAN from being tested. We believe that PRs have been issued for all distributions identified previously. If the number is small\, we could apply pressure on those few authors to get their act together. If we go that route -- and to a certain extent I think we will have to -- here is some suggested language (attachment). A more succinct version. What do you think? (Attached.) ##### "We would appreciate help in sorting this out before the new version of Perl is released in May of this year." #####

As I look at this (and similar language in my original version)\, I'm thinking this is too lenient. A maintainer reading it might think he/she has until mid-May to fix the braces and do a new CPAN release. Because this blocks the testing of other CPAN distros\, I think we should suggest a deadline​: 2 weeks after this message is added to the existing bug ticket.

The reason I picked a shorter version (and perhaps shorter still would be better) is to make this a simple get-it-out-the-door change.

I wouldn't be surprised if some would not be able to make the change within two weeks.

[p5pRT]

From @Leont

On Fri\, Jan 6\, 2017 at 2​:42 PM\, James E Keenan via RT \< perlbug-followup@​perl.org> wrote​:

My recommendations stem from a desire to *not* revert the fatal-left-brace change and a willingness to consequently sustain some breakage when 5.26.0 is released. YMMV.

Quite frankly I think this is not the sort of change that should be hurried. There's lots of code out there\, including DarkPan\, that uses unescaped left braces. This isn't some weird corner case of the language\, but something people did because it worked and was convenient.

Leon

[p5pRT]

From @xsawyerx

On 01/09/2017 11​:51 PM\, Leon Timmermans wrote​:

On Fri\, Jan 6\, 2017 at 2​:42 PM\, James E Keenan via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;perl\.org> wrote​:

My recommendations stem from a desire to \*not\* revert the
fatal\-left\-brace change and a willingness to consequently sustain
some breakage when 5\.26\.0 is released\.  YMMV\.

Quite frankly I think this is not the sort of change that should be hurried. There's lots of code out there\, including DarkPan\, that uses unescaped left braces. This isn't some weird corner case of the language\, but something people did because it worked and was convenient.

If not 5.26\, do you see it then being fatal in 2.28\, 5.30\, or when?

[p5pRT]

From @Leont

On Tue\, Jan 10\, 2017 at 12​:26 PM\, Sawyer X \xsawyerx@&#8203;gmail\.com wrote​:

On 01/09/2017 11​:51 PM\, Leon Timmermans wrote​:

On Fri\, Jan 6\, 2017 at 2​:42 PM\, James E Keenan via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;perl\.org> wrote​:

My recommendations stem from a desire to \*not\* revert the
fatal\-left\-brace change and a willingness to consequently sustain
some breakage when 5\.26\.0 is released\.  YMMV\.

Quite frankly I think this is not the sort of change that should be hurried. There's lots of code out there\, including DarkPan\, that uses unescaped left braces. This isn't some weird corner case of the language\, but something people did because it worked and was convenient.

If not 5.26\, do you see it then being fatal in 2.28\, 5.30\, or when?

According to the document you posted a few days ago\, it's on schedule for 5.30...

Leon

[p5pRT]

From @jkeenan

On Tue\, 10 Jan 2017 18​:13​:38 GMT\, LeonT wrote​:

On Tue\, Jan 10\, 2017 at 12​:26 PM\, Sawyer X \xsawyerx@&#8203;gmail\.com wrote​:

On 01/09/2017 11​:51 PM\, Leon Timmermans wrote​:

On Fri\, Jan 6\, 2017 at 2​:42 PM\, James E Keenan via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;perl\.org> wrote​:

My recommendations stem from a desire to \*not\* revert the
fatal\-left\-brace change and a willingness to consequently sustain
some breakage when 5\.26\.0 is released\.  YMMV\.

Quite frankly I think this is not the sort of change that should be hurried. There's lots of code out there\, including DarkPan\, that uses unescaped left braces. This isn't some weird corner case of the language\, but something people did because it worked and was convenient.

If not 5.26\, do you see it then being fatal in 2.28\, 5.30\, or when?

According to the document you posted a few days ago\, it's on schedule for 5.30...

Leon

No\, that's the *second* round of unescaped-left-brace situations. The *first* round -- scheduled for 5.26 in May -- concerns this in pod/perldiag.pod​:

##### 6285 =item Unescaped left brace in regex is illegal here in regex; 6286 marked by S\<\<-- HERE> in m/%s/ ... #####

This situation is the subject of this RT.

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @Leont

On Tue\, Jan 10\, 2017 at 8​:58 PM\, James E Keenan via RT \< perlbug-followup@​perl.org> wrote​:

On Tue\, 10 Jan 2017 18​:13​:38 GMT\, LeonT wrote​:

On Tue\, Jan 10\, 2017 at 12​:26 PM\, Sawyer X \xsawyerx@&#8203;gmail\.com wrote​:

If not 5.26\, do you see it then being fatal in 2.28\, 5.30\, or when?

According to the document you posted a few days ago\, it's on schedule for 5.30...

No\, that's the *second* round of unescaped-left-brace situations. The *first* round -- scheduled for 5.26 in May -- concerns this in pod/perldiag.pod​:

I see\, I had concluded from the context that it was the other part. It does make me wonder​: is there anything we gain from making some of these cases fatal now when we aren't making them all fatal? It's a rather crude mechanism that doesn't make sense to me without an imminent change of meaning (which won't happen in this case until the second round of deprecations is finalized AFAICT). Causing end-users pain only to motivate authors to update their code seems like a rather poor trade-off to me.

Leon

[p5pRT]

From @khwilliamson

On 01/10/2017 03​:07 PM\, Leon Timmermans wrote​:

On Tue\, Jan 10\, 2017 at 8​:58 PM\, James E Keenan via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;perl\.org> wrote​:

On Tue\, 10 Jan 2017 18​:13​:38 GMT\, LeonT wrote​:
> On Tue\, Jan 10\, 2017 at 12&#8203;:26 PM\, Sawyer X \<xsawyerx@&#8203;gmail\.com
\<mailto&#8203;:xsawyerx@&#8203;gmail\.com>> wrote&#8203;:
> > If not 5\.26\, do you see it then being fatal in 2\.28\, 5\.30\, or when?
>
> According to the document you posted a few days ago\, it's on
schedule for
> 5\.30\.\.\.

No\, that's the \*second\* round of unescaped\-left\-brace situations\.
The \*first\* round \-\- scheduled for 5\.26 in May \-\- concerns this in
pod/perldiag\.pod&#8203;:

I see\, I had concluded from the context that it was the other part. It does make me wonder​: is there anything we gain from making some of these cases fatal now when we aren't making them all fatal? It's a rather crude mechanism that doesn't make sense to me without an imminent change of meaning (which won't happen in this case until the second round of deprecations is finalized AFAICT). Causing end-users pain only to motivate authors to update their code seems like a rather poor trade-off to me.

Leon

As I've said\, it has been my expectation that we would end up reverting this for 5.26. The gain of keeping this fatal for as long as possible in 5.25 would be   1) to get authors to change their code\, hopefully including the rest of the deprecation in one go.   2) possibly this portion of the whole thing could be enough to do some of the planned changes earlier than 5.30 (or so). I used to know this\, but I've forgotten what could be done with just what we have\, and I don't want to go digging it up.

What I think should be done is revert this\, and in early 5.27\, make the whole thing fatal\, planning to revert that before 5.28. This would be to smoke out the modules that need to change\, and start getting them to change. We could revert earlier in 5.27 so as to allow cpan smoking to continue. We might choose to not revert the part that is fatal now\, so that 5.28 could have the benefit of those parts being gone\, and to repurpose whatever it could.

[p5pRT]

From @jkeenan

On Tue\, 10 Jan 2017 23​:56​:23 GMT\, public@​khwilliamson.com wrote​:

On 01/10/2017 03​:07 PM\, Leon Timmermans wrote​:

On Tue\, Jan 10\, 2017 at 8​:58 PM\, James E Keenan via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;perl\.org> wrote​:

On Tue\, 10 Jan 2017 18​:13​:38 GMT\, LeonT wrote​:

On Tue\, Jan 10\, 2017 at 12​:26 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com> wrote​:

If not 5.26\, do you see it then being fatal in 2.28\, 5.30\, or when?

According to the document you posted a few days ago\, it's on schedule for 5.30...

No\, that's the *second* round of unescaped-left-brace situations. The *first* round -- scheduled for 5.26 in May -- concerns this in pod/perldiag.pod​:

I see\, I had concluded from the context that it was the other part. It does make me wonder​: is there anything we gain from making some of these cases fatal now when we aren't making them all fatal? It's a rather crude mechanism that doesn't make sense to me without an imminent change of meaning (which won't happen in this case until the second round of deprecations is finalized AFAICT). Causing end-users pain only to motivate authors to update their code seems like a rather poor trade- off to me.

Leon

As I've said\, it has been my expectation that we would end up reverting this for 5.26. The gain of keeping this fatal for as long as possible in 5.25 would be 1) to get authors to change their code\, hopefully including the rest of the deprecation in one go. 2) possibly this portion of the whole thing could be enough to do some of the planned changes earlier than 5.30 (or so). I used to know this\, but I've forgotten what could be done with just what we have\, and I don't want to go digging it up.

What I think should be done is revert this\, and in early 5.27\, make the whole thing fatal\, planning to revert that before 5.28. This would be to smoke out the modules that need to change\, and start getting them to change. We could revert earlier in 5.27 so as to allow cpan smoking to continue. We might choose to not revert the part that is fatal now\, so that 5.28 could have the benefit of those parts being gone\, and to repurpose whatever it could.

I have to say that this approach seems overly complicated and misguided. We make a change in blead -- but do so not with the intention of having it appear in the next production release. Then\, after we do that production release\, we make another change in blead -- but again without "really" intending it to be in the next production release.

This makes it seem as if blead\, at any given commit\, is not really a preview of the next production release but just a big smoke testing branch. It suggests that blead will only represent a good preview of the next production release in the two or three months immediately preceding that release.

Is this the approach that we are expected to take in the many deprecations coming up in the next two years? It's not one I can summon up much enthusiasm for.

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @khwilliamson

On 01/10/2017 05​:15 PM\, James E Keenan via RT wrote​:

On Tue\, 10 Jan 2017 23​:56​:23 GMT\, public@​khwilliamson.com wrote​:

On 01/10/2017 03​:07 PM\, Leon Timmermans wrote​:

On Tue\, Jan 10\, 2017 at 8​:58 PM\, James E Keenan via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;perl\.org> wrote​:

On Tue\, 10 Jan 2017 18​:13​:38 GMT\, LeonT wrote​:

On Tue\, Jan 10\, 2017 at 12​:26 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com> wrote​:

If not 5.26\, do you see it then being fatal in 2.28\, 5.30\, or when?

According to the document you posted a few days ago\, it's on schedule for 5.30...

No\, that's the *second* round of unescaped-left-brace situations. The *first* round -- scheduled for 5.26 in May -- concerns this in pod/perldiag.pod​:

I see\, I had concluded from the context that it was the other part. It does make me wonder​: is there anything we gain from making some of these cases fatal now when we aren't making them all fatal? It's a rather crude mechanism that doesn't make sense to me without an imminent change of meaning (which won't happen in this case until the second round of deprecations is finalized AFAICT). Causing end-users pain only to motivate authors to update their code seems like a rather poor trade- off to me.

Leon

As I've said\, it has been my expectation that we would end up reverting this for 5.26. The gain of keeping this fatal for as long as possible in 5.25 would be 1) to get authors to change their code\, hopefully including the rest of the deprecation in one go. 2) possibly this portion of the whole thing could be enough to do some of the planned changes earlier than 5.30 (or so). I used to know this\, but I've forgotten what could be done with just what we have\, and I don't want to go digging it up.

What I think should be done is revert this\, and in early 5.27\, make the whole thing fatal\, planning to revert that before 5.28. This would be to smoke out the modules that need to change\, and start getting them to change. We could revert earlier in 5.27 so as to allow cpan smoking to continue. We might choose to not revert the part that is fatal now\, so that 5.28 could have the benefit of those parts being gone\, and to repurpose whatever it could.

I have to say that this approach seems overly complicated and misguided. We make a change in blead -- but do so not with the intention of having it appear in the next production release. Then\, after we do that production release\, we make another change in blead -- but again without "really" intending it to be in the next production release.

I suppose I/we could try a cpan smoke. The only time I tried it\, I got somewhat unsatisfactory results.

This makes it seem as if blead\, at any given commit\, is not really a preview of the next production release but just a big smoke testing branch. It suggests that blead will only represent a good preview of the next production release in the two or three months immediately preceding that release.

Is this the approach that we are expected to take in the many deprecations coming up in the next two years? It's not one I can summon up much enthusiasm for.

It seems unlikely that we would do this again. It's only being done here because we found that authors did not pay attention to the deprecations\, contrary to expectations\, and this deprecation is not really an edge case.

Thank you very much.

[p5pRT]

From @kentfredric

On 11 January 2017 at 13​:15\, James E Keenan via RT \perlbug\-followup@&#8203;perl\.org wrote​:

On Tue\, 10 Jan 2017 23​:56​:23 GMT\, public@​khwilliamson.com wrote​:

On 01/10/2017 03​:07 PM\, Leon Timmermans wrote​:

On Tue\, Jan 10\, 2017 at 8​:58 PM\, James E Keenan via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;perl\.org> wrote​:

On Tue\, 10 Jan 2017 18​:13​:38 GMT\, LeonT wrote​:

On Tue\, Jan 10\, 2017 at 12​:26 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com> wrote​:

If not 5.26\, do you see it then being fatal in 2.28\, 5.30\, or when?

According to the document you posted a few days ago\, it's on schedule for 5.30...

No\, that's the *second* round of unescaped-left-brace situations. The *first* round -- scheduled for 5.26 in May -- concerns this in pod/perldiag.pod​:

I see\, I had concluded from the context that it was the other part. It does make me wonder​: is there anything we gain from making some of these cases fatal now when we aren't making them all fatal? It's a rather crude mechanism that doesn't make sense to me without an imminent change of meaning (which won't happen in this case until the second round of deprecations is finalized AFAICT). Causing end-users pain only to motivate authors to update their code seems like a rather poor trade- off to me.

Leon

As I've said\, it has been my expectation that we would end up reverting this for 5.26. The gain of keeping this fatal for as long as possible in 5.25 would be 1) to get authors to change their code\, hopefully including the rest of the deprecation in one go. 2) possibly this portion of the whole thing could be enough to do some of the planned changes earlier than 5.30 (or so). I used to know this\, but I've forgotten what could be done with just what we have\, and I don't want to go digging it up.

What I think should be done is revert this\, and in early 5.27\, make the whole thing fatal\, planning to revert that before 5.28. This would be to smoke out the modules that need to change\, and start getting them to change. We could revert earlier in 5.27 so as to allow cpan smoking to continue. We might choose to not revert the part that is fatal now\, so that 5.28 could have the benefit of those parts being gone\, and to repurpose whatever it could.

I have to say that this approach seems overly complicated and misguided. We make a change in blead -- but do so not with the intention of having it appear in the next production release. Then\, after we do that production release\, we make another change in blead -- but again without "really" intending it to be in the next production release.

This makes it seem as if blead\, at any given commit\, is not really a preview of the next production release but just a big smoke testing branch. It suggests that blead will only represent a good preview of the next production release in the two or three months immediately preceding that release.

Is this the approach that we are expected to take in the many deprecations coming up in the next two years? It's not one I can summon up much enthusiasm for.

Personally\, I like that approach in effect.

Otherwise\, "we made a break that wasn't in the previous perl but is in the next" is essentially a 1-major-version-behavioural deprecation.

Intended behaviour or unintended behaviour is still behaviour\, and people rely on such behaviour.

Such behaviour should endeavour not to change if at all possible.

And when not possible\, users should get ample warning of the change.

I'd personally like to see a second branch\, that runs in parallel with blead\, "blead-next"\, specifically for attracting these sorts of problems.

eg​:

1. Make change. 2. Change lands in blead 3. blead breaks CPAN 4. Change reverted in blead\, added to blead-next

That way\, "Blead" *really actually is* a "features you will see in your next perl"

As opposed to what it currently is\, which is more akin to the "generic whatever smoke testing target" you've mentioned\, which is currently frequently followed by "panic about all the things broken and mad last minute rush to work out how to ship"

And "Blead-next" is "Stuff that's too dodgy atm to expect in the next major version of perl\, but might be in the one after that"

-- Kent

KENTNL - https://metacpan.org/author/KENTNL

[p5pRT]

From @xsawyerx

On 01/12/2017 03​:59 AM\, Kent Fredric wrote​:

On 11 January 2017 at 13​:15\, James E Keenan via RT \perlbug\-followup@&#8203;perl\.org wrote​:

On Tue\, 10 Jan 2017 23​:56​:23 GMT\, public@​khwilliamson.com wrote​:

On 01/10/2017 03​:07 PM\, Leon Timmermans wrote​:

On Tue\, Jan 10\, 2017 at 8​:58 PM\, James E Keenan via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;perl\.org> wrote​:

On Tue\, 10 Jan 2017 18​:13​:38 GMT\, LeonT wrote​:

On Tue\, Jan 10\, 2017 at 12​:26 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com> wrote​:

If not 5.26\, do you see it then being fatal in 2.28\, 5.30\, or when?

According to the document you posted a few days ago\, it's on schedule for 5.30...

No\, that's the *second* round of unescaped-left-brace situations. The *first* round -- scheduled for 5.26 in May -- concerns this in pod/perldiag.pod​:

I see\, I had concluded from the context that it was the other part. It does make me wonder​: is there anything we gain from making some of these cases fatal now when we aren't making them all fatal? It's a rather crude mechanism that doesn't make sense to me without an imminent change of meaning (which won't happen in this case until the second round of deprecations is finalized AFAICT). Causing end-users pain only to motivate authors to update their code seems like a rather poor trade- off to me.

Leon As I've said\, it has been my expectation that we would end up reverting this for 5.26. The gain of keeping this fatal for as long as possible in 5.25 would be 1) to get authors to change their code\, hopefully including the rest of the deprecation in one go. 2) possibly this portion of the whole thing could be enough to do some of the planned changes earlier than 5.30 (or so). I used to know this\, but I've forgotten what could be done with just what we have\, and I don't want to go digging it up.

What I think should be done is revert this\, and in early 5.27\, make the whole thing fatal\, planning to revert that before 5.28. This would be to smoke out the modules that need to change\, and start getting them to change. We could revert earlier in 5.27 so as to allow cpan smoking to continue. We might choose to not revert the part that is fatal now\, so that 5.28 could have the benefit of those parts being gone\, and to repurpose whatever it could. I have to say that this approach seems overly complicated and misguided. We make a change in blead -- but do so not with the intention of having it appear in the next production release. Then\, after we do that production release\, we make another change in blead -- but again without "really" intending it to be in the next production release.

This makes it seem as if blead\, at any given commit\, is not really a preview of the next production release but just a big smoke testing branch. It suggests that blead will only represent a good preview of the next production release in the two or three months immediately preceding that release.

Is this the approach that we are expected to take in the many deprecations coming up in the next two years? It's not one I can summon up much enthusiasm for.

Personally\, I like that approach in effect.

Otherwise\, "we made a break that wasn't in the previous perl but is in the next" is essentially a 1-major-version-behavioural deprecation.

Intended behaviour or unintended behaviour is still behaviour\, and people rely on such behaviour.

Such behaviour should endeavour not to change if at all possible.

I disagree. Perl is - if I may quote someone who quoted someone - a hyper-dynamic language. Many constructs work in it\, even if they were not planned. That's a wonderful thing. However\, at the same time\, this easily lends to a trap that forces core developers to support various awkward syntax someone was able to concoct\, just because said users refuses to change their code. This means we have a hard time fixing unintended syntax and to build bigger and greater things because of it. This includes refactoring\, optimizations\, new features\, and so on.

There has to be a balance\, allowing us to both move forward and to respect anything that simply either cannot be done in a certain way or is just rooted within the language (example​: bare heredoc terminators). That balance has to take into account that some things must change\, and that it doesn't fall under "at all possible" to avoid. Perhaps we differ on the definition of "if possible" and my barrier is lower.

Rephrasing my position more clearly\, I think we *can* avoid a lot of change\, but *shouldn't* do so.

"Things alter for the worse spontaneously\, if they be not altered for the better designedly." -- Francis Bacon

And when not possible\, users should get ample warning of the change.

I'd personally like to see a second branch\, that runs in parallel with blead\, "blead-next"\, specifically for attracting these sorts of problems.

eg​:

1. Make change. 2. Change lands in blead 3. blead breaks CPAN 4. Change reverted in blead\, added to blead-next

I think in some cases this is possible and it is done. In some cases it isn't possible\, and in some cases it is possible but not done. I think we should remain flexible on this.

Going back to the original discussion on the value of making this change this way vs. reverting and then doing it again​: there is a considerable value in doing it now. Introducing iterative changes is easier (for users) than introducing one major breakage that includes many different changes. There weren't that many breakages and we have provided patches for most.

[p5pRT]

From @kentfredric

On 15 January 2017 at 09​:38\, Sawyer X \xsawyerx@&#8203;gmail\.com wrote​:

Rephrasing my position more clearly\, I think we *can* avoid a lot of change\, but *shouldn't* do so.

I have no opposition of changes that introduce new behaviour.

This is not a conflict of interest.

I only have opposition to changes that break *existing* behaviour\, which should be done with a lot more forethought and care.

The question is of necessity.

Changing it because you want to is not necessity.

Changing it to make way for an existing and defined alternative that justifies itself in advantage over the existing behaviour is broaching on necessity\, and then\, its often a case that the person who thought it necessary didn't think about it hard enough.

And that\, once considering and understanding all of the above\, under the presumption one still reaches a "we have to change this"\, then the argument reduces to /how quickly/ you make that change.

And the most *responsible* thing to do here is to maximise the audience and time in which to make that change\, keeping in mind\, that our changes break systems of people who are not actively participating in p5p discussions.

And we are *actively* at a *great disservice* to those users if perl changes too quickly for them to keep up.

Because if they can't expect their existing software to work on newer versions of perls\, then they are making a choice to stick with older versions of perls\, because their hand has been forced by P5P to use older perls because their entrenched and complex system has not been updated to work on it yet\, because P5P ploughed ahead and considered "software broken? somebody elses problem\, its deprecated"

And this means they benefit _Zero_ from any security fixes we apply.

And so a growing mentality of "break all the backcompat" turns into a "Guarantee a growing number of installations remain vulnerable".

Change only what is necessary.

Because the more you change\, the number of interactions between those changes grows exponentially.

And so you trap yourself in a cycle of making changes because you made previous changes\, the act of work creates more work for yourself ( and everyone else ).

And somehow\, this scale breaking of software is seen as progress.

As for francis bacon​:

If the Perl5 Source code is spontaneously changing for the worse\, I want to know who gave commit bits to a random number generator.

The only way it can spontaneously change for the worse\, is if we *let people make it so*

And if we're spontaneously changing things for the worse under the guise of progress ...

-- Kent

KENTNL - https://metacpan.org/author/KENTNL

[p5pRT]

From @xsawyerx

[Top-posting]

In all honesty\, I'm a bit spent having this discussion at so many random turns of the corner. Instead of discussing a specific issue at hand\, it often comes back to "Can we try to avoid changing anything?" vs. "Can we change as much as possible?"

If it's alright with you\, I'll summarize what I wish to convey and move on from this.

I agree we should not break things when unnecessary. I disagree with your definition for "unnecessary". However\, whether we agree or not on the definition is less important to me\, but the agreement we have on being judicious and careful with our changes\, as I believe we both understand that there are real implications to change\, far from our collective view. This balancing act will forever remain\, but as with any balancing act\, it is a continuous adjustment. That means we must remain flexible and continue to doubt both our decision to keep something and our decision to remove something.

I don't think we will - or that we even should - reach a situation of "always" or "never"\, which renders these discussion less than productive.

On 01/15/2017 01​:31 PM\, Kent Fredric wrote​:

On 15 January 2017 at 09​:38\, Sawyer X \xsawyerx@&#8203;gmail\.com wrote​:

Rephrasing my position more clearly\, I think we *can* avoid a lot of change\, but *shouldn't* do so.

I have no opposition of changes that introduce new behaviour.

This is not a conflict of interest.

I only have opposition to changes that break *existing* behaviour\, which should be done with a lot more forethought and care.

The question is of necessity.

Changing it because you want to is not necessity.

Changing it to make way for an existing and defined alternative that justifies itself in advantage over the existing behaviour is broaching on necessity\, and then\, its often a case that the person who thought it necessary didn't think about it hard enough.

And that\, once considering and understanding all of the above\, under the presumption one still reaches a "we have to change this"\, then the argument reduces to /how quickly/ you make that change.

And the most *responsible* thing to do here is to maximise the audience and time in which to make that change\, keeping in mind\, that our changes break systems of people who are not actively participating in p5p discussions.

And we are *actively* at a *great disservice* to those users if perl changes too quickly for them to keep up.

Because if they can't expect their existing software to work on newer versions of perls\, then they are making a choice to stick with older versions of perls\, because their hand has been forced by P5P to use older perls because their entrenched and complex system has not been updated to work on it yet\, because P5P ploughed ahead and considered "software broken? somebody elses problem\, its deprecated"

And this means they benefit _Zero_ from any security fixes we apply.

And so a growing mentality of "break all the backcompat" turns into a "Guarantee a growing number of installations remain vulnerable".

Change only what is necessary.

Because the more you change\, the number of interactions between those changes grows exponentially.

And so you trap yourself in a cycle of making changes because you made previous changes\, the act of work creates more work for yourself ( and everyone else ).

And somehow\, this scale breaking of software is seen as progress.

As for francis bacon​:

If the Perl5 Source code is spontaneously changing for the worse\, I want to know who gave commit bits to a random number generator.

The only way it can spontaneously change for the worse\, is if we *let people make it so*

And if we're spontaneously changing things for the worse under the guise of progress ...

[p5pRT]

From @kentfredric

On 16 January 2017 at 03​:18\, Sawyer X \xsawyerx@&#8203;gmail\.com wrote​:

I don't think we will - or that we even should - reach a situation of "always" or "never"\, which renders these discussion less than productive.

I'm not saying its a situation of "always"\, or "never".

Its a matter of defaults\, and initial perspectives and emotionally motivated biases.

Just like there's axiomic "innocent until proven guilty" in court\, in software\, we should take the approach of "harmful until proven safe"\, not "beneficial until proven bad"

Its like the person who has a couple of beers and might be over the legal limit\, or might not be\, and they justify to themselves through their motivated reasoning that "I'll be alright\, its not far\, I'll take a back road etc"\, whereas the people who write the transport code would rather you considered literally any level of intoxication as an inhibitor to reaction times\, and that you should default to not driving at all after any amount of alcohol.

The second group runs a risk of being inconvenienced\, but the first group gets to play "will I kill somebody or not"

You seem to be on the side of the fence that is emotionally motivated to derive change in all aspects you touch\, and that will taint all your choices towards the conflicting one\, because you default to "we should change the things" and you then make it our duty to convince you not to change something.

Whereas the change that creates conflict should be on the other side of the fence\, we should assume that the conflict will exist\, and then take steps to demonstrate the safety\, proving to ourselves via evidence that it is justified.

And given that safety/unsafety of software is difficult to do well in itself\, we should take BBC failures as not merely a signal of a single problem\, but we should read each and every BBC as a tip of an unseen shadow of problems.

Also\, consider the fact I am already greatly aware of much more stringent views in regards to vehement lack of change\, and that my proposals/suggestions with regards to *graduated* change was itself\, _already_ an attempt at compromise/balance between the two poles.

You're trying to find a balancing point between your broad ideal and that\, not your broad ideal and strict conservatism.

All I'm trying to achieve is to simply slow down the rate of attrition\, so the number of radical changes that break CPAN spread out over a longer time\, not invoke a curse of "thou shall not change".

-- Kent

KENTNL - https://metacpan.org/author/KENTNL

[p5pRT]

From @Leont

On Sat\, Jan 14\, 2017 at 9​:38 PM\, Sawyer X \xsawyerx@&#8203;gmail\.com wrote​:

Going back to the original discussion on the value of making this change this way vs. reverting and then doing it again​: there is a considerable value in doing it now. Introducing iterative changes is easier (for users) than introducing one major breakage that includes many different changes.

Can you concretize this for me? Preferably something like "doing this now enables us to do X in the next release\, which would otherwise not be possible".

Given the other left-braces warning I don't see how there is any X for the next two releases\, making this hurry pointless to me.

Leon

[p5pRT]

From @xsawyerx

On 01/16/2017 07​:28 PM\, Leon Timmermans wrote​:

On Sat\, Jan 14\, 2017 at 9​:38 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com> wrote​:

Going back to the original discussion on the value of making this
change
this way vs\. reverting and then doing it again​: there is a
considerable
value in doing it now\. Introducing iterative changes is easier \(for
users\) than introducing one major breakage that includes many
different
changes\.

Can you concretize this for me? Preferably something like "doing this now enables us to do X in the next release\, which would otherwise not be possible".

I'm not sure this is the best way to phrase what I meant\, but let me try using these terms​:

The regular expression syntax has been cleaning up over time. This allowed us to remove possible problems\, clean up confusing syntax\, tighten up the syntax\, and even add features (/xx was just reused a few commits ago by khw). This specifically is a good example\, because it shows khw's long-term plans\, which he works out in piecemeal\, making small changes each time\, eventually create enough room to introduce something new.

If we had done all the changes that would facilitate these new features or fixes in one pass\, it would have broken a wider range of modules and programs in numerous ways. This would have taken longer to figure out\, to provide pull requests and patches for\, to convince authors to merge and release new versions\, and could eventually lead to more frustration with authors who have written code that now broke in multiple ways.

My point is that while this breakage *will* occur\, there is an value in making only *this* one this time\, instead of this *plus* another in the next version. That's not to say I'm strongly opposed to reverting this. Neither is Karl.

Given the other left-braces warning I don't see how there is any X for the next two releases\, making this hurry pointless to me.

I'm sorry. I didn't understand this sentence.

[p5pRT]

From @Leont

On Tue\, Jan 17\, 2017 at 9​:10 PM\, Sawyer X \xsawyerx@&#8203;gmail\.com wrote​:

On 01/16/2017 07​:28 PM\, Leon Timmermans wrote​:

On Sat\, Jan 14\, 2017 at 9​:38 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com> wrote​:

Going back to the original discussion on the value of making this
change
this way vs\. reverting and then doing it again​: there is a
considerable
value in doing it now\. Introducing iterative changes is easier \(for
users\) than introducing one major breakage that includes many
different
changes\.

Can you concretize this for me? Preferably something like "doing this now enables us to do X in the next release\, which would otherwise not be possible".

I'm not sure this is the best way to phrase what I meant\, but let me try using these terms​:

The regular expression syntax has been cleaning up over time. This allowed us to remove possible problems\, clean up confusing syntax\, tighten up the syntax\, and even add features (/xx was just reused a few commits ago by khw). This specifically is a good example\, because it shows khw's long-term plans\, which he works out in piecemeal\, making small changes each time\, eventually create enough room to introduce something new.

If we had done all the changes that would facilitate these new features or fixes in one pass\, it would have broken a wider range of modules and programs in numerous ways. This would have taken longer to figure out\, to provide pull requests and patches for\, to convince authors to merge and release new versions\, and could eventually lead to more frustration with authors who have written code that now broke in multiple ways.

My point is that while this breakage *will* occur\, there is an value in making only *this* one this time\, instead of this *plus* another in the next version. That's not to say I'm strongly opposed to reverting this. Neither is Karl.

I think you missed my point\, you're giving a philosophical answer where I'm asking for a tangible result.

Given the other left-braces warning I don't see how there is any X for

the next two releases\, making this hurry pointless to me.

I'm sorry. I didn't understand this sentence.

As far as I know\, Karl (correct me if I'm wrong) can't execute his long-term braces plan (a tangible result) until the other warning becomes fatal too (after 5.30). Not fatalizing this warning now will not obstruct any future plans as far as I can tell\, and will allow for a smoother upgrade path to 5.26 (giving people more time to escape their braces).

Leon

[p5pRT]

From @khwilliamson

On 01/17/2017 02​:52 PM\, Leon Timmermans wrote​:

On Tue\, Jan 17\, 2017 at 9​:10 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com> wrote​:

On 01/16/2017 07​:28 PM\, Leon Timmermans wrote​:
> On Sat\, Jan 14\, 2017 at 9&#8203;:38 PM\, Sawyer X \<xsawyerx@&#8203;gmail\.com \<mailto&#8203;:xsawyerx@&#8203;gmail\.com>
> \<mailto&#8203;:xsawyerx@&#8203;gmail\.com \<mailto&#8203;:xsawyerx@&#8203;gmail\.com>>> wrote&#8203;:
>
>     Going back to the original discussion on the value of making this
>     change
>     this way vs\. reverting and then doing it again&#8203;: there is a
>     considerable
>     value in doing it now\. Introducing iterative changes is easier \(for
>     users\) than introducing one major breakage that includes many
>     different
>     changes\.
>
>
> Can you concretize this for me? Preferably something like "doing this
> now enables us to do X in the next release\, which would otherwise not
> be possible"\.

I'm not sure this is the best way to phrase what I meant\, but let me try
using these terms&#8203;:

The regular expression syntax has been cleaning up over time\. This
allowed us to remove possible problems\, clean up confusing syntax\,
tighten up the syntax\, and even add features \(/xx was just reused a few
commits ago by khw\)\. This specifically is a good example\, because it
shows khw's long\-term plans\, which he works out in piecemeal\, making
small changes each time\, eventually create enough room to introduce
something new\.

If we had done all the changes that would facilitate these new features
or fixes in one pass\, it would have broken a wider range of modules and
programs in numerous ways\. This would have taken longer to figure out\,
to provide pull requests and patches for\, to convince authors to merge
and release new versions\, and could eventually lead to more frustration
with authors who have written code that now broke in multiple ways\.

My point is that while this breakage \*will\* occur\, there is an value in
making only \*this\* one this time\, instead of this \*plus\* another in the
next version\. That's not to say I'm strongly opposed to reverting this\.
Neither is Karl\.

I think you missed my point\, you're giving a philosophical answer where I'm asking for a tangible result.

> Given the other left\-braces warning I don't see how there is any X for
> the next two releases\, making this hurry pointless to me\.

I'm sorry\. I didn't understand this sentence\.

As far as I know\, Karl (correct me if I'm wrong) can't execute his long-term braces plan (a tangible result) until the other warning becomes fatal too (after 5.30). Not fatalizing this warning now will not obstruct any future plans as far as I can tell\, and will allow for a smoother upgrade path to 5.26 (giving people more time to escape their braces).

Leon

I'd have to spend some time figuring out what could be done with the portion of the braces gone in 5.28. As I recall\, it wouldn't be a lot. That's why I haven't been too concerned about reverting.

But since this is viewed as a bug fix\, it doesn't have to be done in time for the visible changes load\, so we have more time to discuss it.

[p5pRT]

From @jkeenan

On Fri\, 20 Jan 2017 00​:36​:59 GMT\, public@​khwilliamson.com wrote​:

On 01/17/2017 02​:52 PM\, Leon Timmermans wrote​:

On Tue\, Jan 17\, 2017 at 9​:10 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com> wrote​:

On 01/16/2017 07​:28 PM\, Leon Timmermans wrote​:

On Sat\, Jan 14\, 2017 at 9​:38 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com \<mailto​:xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com>> wrote​:

Going back to the original discussion on the value of making this change this way vs. reverting and then doing it again​: there is a considerable value in doing it now. Introducing iterative changes is easier (for users) than introducing one major breakage that includes many different changes.

Can you concretize this for me? Preferably something like "doing this now enables us to do X in the next release\, which would otherwise not be possible".

I'm not sure this is the best way to phrase what I meant\, but let me try using these terms​:

The regular expression syntax has been cleaning up over time. This allowed us to remove possible problems\, clean up confusing syntax\, tighten up the syntax\, and even add features (/xx was just reused a few commits ago by khw). This specifically is a good example\, because it shows khw's long-term plans\, which he works out in piecemeal\, making small changes each time\, eventually create enough room to introduce something new.

If we had done all the changes that would facilitate these new features or fixes in one pass\, it would have broken a wider range of modules and programs in numerous ways. This would have taken longer to figure out\, to provide pull requests and patches for\, to convince authors to merge and release new versions\, and could eventually lead to more frustration with authors who have written code that now broke in multiple ways.

My point is that while this breakage *will* occur\, there is an value in making only *this* one this time\, instead of this *plus* another in the next version. That's not to say I'm strongly opposed to reverting this. Neither is Karl.

I think you missed my point\, you're giving a philosophical answer where I'm asking for a tangible result.

> Given the other left\-braces warning I don't see how there is
> any X for
> the next two releases\, making this hurry pointless to me\.

I'm sorry. I didn't understand this sentence.

As far as I know\, Karl (correct me if I'm wrong) can't execute his long-term braces plan (a tangible result) until the other warning becomes fatal too (after 5.30). Not fatalizing this warning now will not obstruct any future plans as far as I can tell\, and will allow for a smoother upgrade path to 5.26 (giving people more time to escape their braces).

Leon

I'd have to spend some time figuring out what could be done with the portion of the braces gone in 5.28. As I recall\, it wouldn't be a lot. That's why I haven't been too concerned about reverting.

But since this is viewed as a bug fix\, it doesn't have to be done in time for the visible changes load\, so we have more time to discuss it.

Until Jan 31 CPANtesters was impeded from getting a full picture of the impact of this fatalization on the building and testing of CPAN distributions because one distribution with over 600 first-level reverse dependencies was failing for this reason in one test\, preventing the full testing of that distribution and all distributions which depended upon it.

That situation has now been remedied. (Kudos to Toby\, Nigel\, sawyer and many others for their attention to this situation.) CPANtesters is therefore now in a much better position to assess the impact of this fatalization on CPAN as we head to 5.26.0.

Over the last week I used 'cpanm' to build and test that distribution (Type-Tiny) and all its reverse dependencies. I am pleased to report that I discovered only one previously unreported instance of a CPAN distribution getting a FAIL due to this fatalization. I filed a bug report for that ticket. Slaven\, Andreas\, Karen E and others have already filed bug reports for all other CPAN distributions experiencing FAILs due to this fatalization. (Details available upon request.)

Therefore IMO there is no significant barrier to the implementation of this fatalization in 5.26.0. I would not be in favor of delaying this implementation until 5.28\, though I acknowledge other people think otherwise. But we have IMO taken every step we practically can to warn users of potential problems.

Hence\, I recommend that we *not* perform the reversion cited in the subject of this ticket.

Thank you very much. Jim Keenan

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @khwilliamson

On Mon\, 06 Feb 2017 08​:23​:25 -0800\, jkeenan wrote​:

On Fri\, 20 Jan 2017 00​:36​:59 GMT\, public@​khwilliamson.com wrote​:

On 01/17/2017 02​:52 PM\, Leon Timmermans wrote​:

On Tue\, Jan 17\, 2017 at 9​:10 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com> wrote​:

On 01/16/2017 07​:28 PM\, Leon Timmermans wrote​:

On Sat\, Jan 14\, 2017 at 9​:38 PM\, Sawyer X \<xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com \<mailto​:xsawyerx@​gmail.com \mailto&#8203;:xsawyerx@&#8203;gmail\.com>> wrote​:

Going back to the original discussion on the value of making this change this way vs. reverting and then doing it again​: there is a considerable value in doing it now. Introducing iterative changes is easier (for users) than introducing one major breakage that includes many different changes.

Can you concretize this for me? Preferably something like "doing this now enables us to do X in the next release\, which would otherwise not be possible".

I'm not sure this is the best way to phrase what I meant\, but let me try using these terms​:

The regular expression syntax has been cleaning up over time. This allowed us to remove possible problems\, clean up confusing syntax\, tighten up the syntax\, and even add features (/xx was just reused a few commits ago by khw). This specifically is a good example\, because it shows khw's long-term plans\, which he works out in piecemeal\, making small changes each time\, eventually create enough room to introduce something new.

If we had done all the changes that would facilitate these new features or fixes in one pass\, it would have broken a wider range of modules and programs in numerous ways. This would have taken longer to figure out\, to provide pull requests and patches for\, to convince authors to merge and release new versions\, and could eventually lead to more frustration with authors who have written code that now broke in multiple ways.

My point is that while this breakage *will* occur\, there is an value in making only *this* one this time\, instead of this *plus* another in the next version. That's not to say I'm strongly opposed to reverting this. Neither is Karl.

I think you missed my point\, you're giving a philosophical answer where I'm asking for a tangible result.

> Given the other left\-braces warning I don't see how there is
> any X for
> the next two releases\, making this hurry pointless to me\.

I'm sorry. I didn't understand this sentence.

As far as I know\, Karl (correct me if I'm wrong) can't execute his long-term braces plan (a tangible result) until the other warning becomes fatal too (after 5.30). Not fatalizing this warning now will not obstruct any future plans as far as I can tell\, and will allow for a smoother upgrade path to 5.26 (giving people more time to escape their braces).

Leon

I'd have to spend some time figuring out what could be done with the portion of the braces gone in 5.28. As I recall\, it wouldn't be a lot. That's why I haven't been too concerned about reverting.

But since this is viewed as a bug fix\, it doesn't have to be done in time for the visible changes load\, so we have more time to discuss it.

Until Jan 31 CPANtesters was impeded from getting a full picture of the impact of this fatalization on the building and testing of CPAN distributions because one distribution with over 600 first-level reverse dependencies was failing for this reason in one test\, preventing the full testing of that distribution and all distributions which depended upon it.

That situation has now been remedied. (Kudos to Toby\, Nigel\, sawyer and many others for their attention to this situation.) CPANtesters is therefore now in a much better position to assess the impact of this fatalization on CPAN as we head to 5.26.0.

Over the last week I used 'cpanm' to build and test that distribution (Type-Tiny) and all its reverse dependencies. I am pleased to report that I discovered only one previously unreported instance of a CPAN distribution getting a FAIL due to this fatalization. I filed a bug report for that ticket. Slaven\, Andreas\, Karen E and others have already filed bug reports for all other CPAN distributions experiencing FAILs due to this fatalization. (Details available upon request.)

Therefore IMO there is no significant barrier to the implementation of this fatalization in 5.26.0. I would not be in favor of delaying this implementation until 5.28\, though I acknowledge other people think otherwise. But we have IMO taken every step we practically can to warn users of potential problems.

Hence\, I recommend that we *not* perform the reversion cited in the subject of this ticket.

Thank you very much. Jim Keenan

It occurs to me another argument in favor of keeping it fatal is\, as I've said before\, I think it is safer when making a change that can cause working programs to have a different behavior\, to have that syntax to be fatal for a release or two. That's why I originally was going to have /xx be fatal for 5.26. But the fact that it was fatal during essentially the entirety of the 5.25 series without a single BBC report convinced me it was ok to go ahead and change the meaning.

I think that by making this portion of the unescaped '{' fatal in 5.26\, we will lessen the chances that the final portion will create problems in future releases. -- Karl Williamson

[p5pRT]

From @jkeenan

On Wed\, 08 Feb 2017 17​:18​:13 GMT\, khw wrote​: [snip]

I think that by making this portion of the unescaped '{' fatal in 5.26\, we will lessen the chances that the final portion will create problems in future releases.

I agree with that. It will also give us a feel for the scope of the problems we'll face with fatalizations/new exceptions in 5.28 and 5.30.

Thank you very much. Jim Keenan -- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @iabyn

On Wed\, Feb 08\, 2017 at 10​:19​:25AM -0800\, James E Keenan via RT wrote​:

On Wed\, 08 Feb 2017 17​:18​:13 GMT\, khw wrote​: [snip]

I think that by making this portion of the unescaped '{' fatal in 5.26\, we will lessen the chances that the final portion will create problems in future releases.

I agree with that. It will also give us a feel for the scope of the problems we'll face with fatalizations/new exceptions in 5.28 and 5.30.

If I've read this thread correctly\, there is now a consensus that the new fatal warning should be kept for 5.26.0. Unless anyone objects\, I'll remove this ticket from the 5.26.0 blockers in a few days time.

-- Hofstadter's Law​: It always takes longer than you expect\, even when you take into account Hofstadter's Law.

[p5pRT]

From @iabyn

On Mon\, Mar 20\, 2017 at 02​:28​:53PM +0000\, Dave Mitchell wrote​:

Unless anyone objects\, I'll remove this ticket from the 5.26.0 blockers in a few days time.

Now done.

-- "Do not dabble in paradox\, Edward\, it puts you in danger of fortuitous wit."   -- Lady Croom\, "Arcadia"

[p5pRT]

From @iabyn

On Mon\, Mar 20\, 2017 at 02​:28​:53PM +0000\, Dave Mitchell wrote​:

If I've read this thread correctly\, there is now a consensus that the new fatal warning should be kept for 5.26.0. Unless anyone objects\, I'll remove this ticket from the 5.26.0 blockers in a few days time.

Now removed.

-- "You're so sadly neglected\, and often ignored. A poor second to Belgium\, When going abroad."   -- Monty Python\, "Finland"

[p5pRT]

From @khwilliamson

On Mon\, 27 Mar 2017 03​:38​:20 -0700\, davem wrote​:

On Mon\, Mar 20\, 2017 at 02​:28​:53PM +0000\, Dave Mitchell wrote​:

If I've read this thread correctly\, there is now a consensus that the new fatal warning should be kept for 5.26.0. Unless anyone objects\, I'll remove this ticket from the 5.26.0 blockers in a few days time.

Now removed.

It seems to me that this ticket can be closed\, and I'll do so in a week unless there is reasonable objection -- Karl Williamson

[p5pRT]

From @khwilliamson

We decided to not revert; rejected -- Karl Williamson

[p5pRT]

@khwilliamson - Status changed from 'open' to 'rejected'