Skip Menu |

To: perlbug [...] perl.org
Date: Tue, 03 Jan 2017 23:00:29 +0100
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: Revert "Unescaped left brace in regex" fatality
I apologize that I did not wake up when I was reading the following dialog in the meanwhile closed ticket #128139: Show quoted text
>>>>> On Thu, 8 Dec 2016 13:44:32 -0700, Karl Williamson <public@khwilliamson.com> said:
Show quoted text
> 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?
Show quoted text
> 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 .
RT-Send-CC: perl5-porters [...] perl.org
On Tue, 03 Jan 2017 22:00:53 GMT, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote: Show quoted text
> 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)
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
To: "James E Keenan via RT" <perlbug-followup [...] perl.org>
Date: Wed, 04 Jan 2017 08:48:31 +0100
Download (untitled) / with headers
text/plain 7.4k
Show quoted text
>>>>> 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.
Show quoted text
> 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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 7.3k
On Wed, 04 Jan 2017 07:49:51 GMT, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote: Show quoted text
> >>>>> 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)
Subject: fatal-brace-with-dependencies-20170104.psv

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 8.1k
On Wed, 04 Jan 2017 13:29:49 GMT, jkeenan wrote: Show quoted text
> 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)
Subject: fatal-brace-with-dependencies-20170104.txt
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||
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 802b
On Wed, 04 Jan 2017 13:29:49 GMT, jkeenan wrote: Show quoted text
> > 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)
RT-Send-CC: perl5-porters [...] perl.org
Noticed this ticket by accident... Shipped fixed version of ZOFFIX/App-ZofCMS to CPAN
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Karl Williamson <khw [...] indra.com>
To: perlbug-followup [...] perl.org
Date: Tue, 3 Jan 2017 15:50:50 -0700
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
On 1/3/2017 3:42 PM, James E Keenan via RT wrote: Show quoted text
> 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. Show quoted text
> > Thank you very much. >
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Thu, 05 Jan 2017 14:07:29 GMT, khw@indra.com wrote: Show quoted text
> > > 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? Show quoted text
> 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)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Thu, 05 Jan 2017 14:07:29 GMT, khw@indra.com wrote: Show quoted text
> > > 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). Show quoted text
> If large or they are obstinate, we will have to revert.
> > > > Thank you very much. > >
-- James E Keenan (jkeenan@cpan.org)
Subject: unpatched-distros-with-dependencies.txt
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.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 450b
On Wed, 04 Jan 2017 13:34:03 GMT, jkeenan wrote: Show quoted text
> 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)
CC: perl5-porters [...] perl.org
From: Sawyer X <xsawyerx [...] gmail.com>
Date: Fri, 6 Jan 2017 10:18:48 +0100
To: Karl Williamson <khw [...] indra.com>, perlbug-followup [...] perl.org
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 1.6k
On 01/03/2017 11:50 PM, Karl Williamson wrote: Show quoted text
> > > 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?
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
CC: perl5-porters [...] perl.org
From: Sawyer X <xsawyerx [...] gmail.com>
Date: Fri, 6 Jan 2017 10:35:15 +0100
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On 01/05/2017 04:15 PM, James E Keenan via RT wrote: Show quoted text
> 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.)

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.3k
On Fri, 06 Jan 2017 09:36:01 GMT, xsawyerx@gmail.com wrote: Show quoted text
> > > 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)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.9k
On Fri, 06 Jan 2017 09:19:35 GMT, xsawyerx@gmail.com wrote: Show quoted text
> > > 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)
From: Sawyer X <xsawyerx [...] gmail.com>
Date: Mon, 9 Jan 2017 12:39:39 +0100
To: perl5-porters [...] perl.org
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
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: Show quoted text
> 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.
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
To: perl5-porters [...] perl.org
Date: Mon, 9 Jan 2017 12:58:29 +0100
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 2.6k
This failed yesterday, so I'm trying it again today. On 01/06/2017 02:27 PM, James E Keenan via RT wrote: Show quoted text
> 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.
To: perlbug <perlbug-followup [...] perl.org>
Date: Mon, 9 Jan 2017 23:51:43 +0100
From: Leon Timmermans <fawaka [...] gmail.com>
CC: Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 551b
On Fri, Jan 6, 2017 at 2:42 PM, James E Keenan via RT <perlbug-followup@perl.org> wrote:
Show quoted text
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

Date: Tue, 10 Jan 2017 12:26:47 +0100
To: perl5-porters [...] perl.org
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 722b
On 01/09/2017 11:51 PM, Leon Timmermans wrote: Show quoted text
> On Fri, Jan 6, 2017 at 2:42 PM, James E Keenan via RT > <perlbug-followup@perl.org <mailto: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.
If not 5.26, do you see it then being fatal in 2.28, 5.30, or when?
Date: Tue, 10 Jan 2017 19:12:26 +0100
To: Sawyer X <xsawyerx [...] gmail.com>
From: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
CC: Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 913b
On Tue, Jan 10, 2017 at 12:26 PM, Sawyer X <xsawyerx@gmail.com> wrote:
Show quoted text
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: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.

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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
On Tue, 10 Jan 2017 18:13:38 GMT, LeonT wrote: Show quoted text
> On Tue, Jan 10, 2017 at 12:26 PM, Sawyer X <xsawyerx@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: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.
> > > > 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)
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
CC: Perl5 Porters <perl5-porters [...] perl.org>
From: Leon Timmermans <fawaka [...] gmail.com>
To: perlbug <perlbug-followup [...] perl.org>
Date: Tue, 10 Jan 2017 23:07:53 +0100
On Tue, Jan 10, 2017 at 8:58 PM, James E Keenan via RT <perlbug-followup@perl.org> wrote:
Show quoted text
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> 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
To: Leon Timmermans <fawaka [...] gmail.com>, perlbug <perlbug-followup [...] perl.org>
Date: Tue, 10 Jan 2017 16:55:30 -0700
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
CC: Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 2.1k
On 01/10/2017 03:07 PM, Leon Timmermans wrote: Show quoted text
> On Tue, Jan 10, 2017 at 8:58 PM, James E Keenan via RT > <perlbug-followup@perl.org <mailto: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@gmail.com
> <mailto:xsawyerx@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.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.1k
On Tue, 10 Jan 2017 23:56:23 GMT, public@khwilliamson.com wrote: Show quoted text
> 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: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@gmail.com
> > <mailto:xsawyerx@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)
Date: Tue, 10 Jan 2017 17:23:30 -0700
To: perlbug-followup [...] perl.org
From: Karl Williamson <public [...] khwilliamson.com>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 3.5k
On 01/10/2017 05:15 PM, James E Keenan via RT wrote: Show quoted text
> 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: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@gmail.com
>>> <mailto:xsawyerx@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. Show quoted text
> > 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. Show quoted text
> > Thank you very much. >
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Date: Thu, 12 Jan 2017 15:59:17 +1300
To: Lukas Mai via RT <perlbug-followup [...] perl.org>
From: Kent Fredric <kentfredric [...] gmail.com>
CC: pp Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 4.4k
On 11 January 2017 at 13:15, James E Keenan via RT <perlbug-followup@perl.org> wrote: Show quoted text
> 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: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@gmail.com
>> > <mailto:xsawyerx@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
CC: pp Porters <perl5-porters [...] perl.org>
From: Sawyer X <xsawyerx [...] gmail.com>
To: Kent Fredric <kentfredric [...] gmail.com>, Lukas Mai via RT <perlbug-followup [...] perl.org>
Date: Sat, 14 Jan 2017 21:38:59 +0100
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 5.7k
On 01/12/2017 03:59 AM, Kent Fredric wrote: Show quoted text
> On 11 January 2017 at 13:15, James E Keenan via RT > <perlbug-followup@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: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@gmail.com
>>>> <mailto:xsawyerx@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 Show quoted text
> 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.
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Kent Fredric <kentfredric [...] gmail.com>
To: Sawyer X <xsawyerx [...] gmail.com>
Date: Mon, 16 Jan 2017 01:31:40 +1300
Download (untitled) / with headers
text/plain 2.5k
On 15 January 2017 at 09:38, Sawyer X <xsawyerx@gmail.com> wrote: Show quoted text
> 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
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Date: Sun, 15 Jan 2017 15:18:32 +0100
To: Kent Fredric <kentfredric [...] gmail.com>
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 3.7k
[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: Show quoted text
> On 15 January 2017 at 09:38, Sawyer X <xsawyerx@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 ... >
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
To: Sawyer X <xsawyerx [...] gmail.com>
Date: Mon, 16 Jan 2017 08:35:53 +1300
From: Kent Fredric <kentfredric [...] gmail.com>
Download (untitled) / with headers
text/plain 2.4k
On 16 January 2017 at 03:18, Sawyer X <xsawyerx@gmail.com> wrote: Show quoted text
> > 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
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
CC: Kent Fredric <kentfredric [...] gmail.com>, Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
From: Leon Timmermans <fawaka [...] gmail.com>
To: Sawyer X <xsawyerx [...] gmail.com>
Date: Mon, 16 Jan 2017 19:28:07 +0100
Download (untitled) / with headers
text/plain 667b
On Sat, Jan 14, 2017 at 9:38 PM, Sawyer X <xsawyerx@gmail.com> wrote:
Show quoted text
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
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Date: Tue, 17 Jan 2017 21:10:43 +0100
To: Leon Timmermans <fawaka [...] gmail.com>
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 1.9k
On 01/16/2017 07:28 PM, Leon Timmermans wrote: Show quoted text
> On Sat, Jan 14, 2017 at 9:38 PM, Sawyer X <xsawyerx@gmail.com > <mailto:xsawyerx@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. Show quoted text
> > 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.
From: Leon Timmermans <fawaka [...] gmail.com>
Date: Tue, 17 Jan 2017 22:52:43 +0100
To: Sawyer X <xsawyerx [...] gmail.com>
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 2.5k
On Tue, Jan 17, 2017 at 9:10 PM, Sawyer X <xsawyerx@gmail.com> wrote:
Show quoted text
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:xsawyerx@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.

Show quoted text
> 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
To: Leon Timmermans <fawaka [...] gmail.com>, Sawyer X <xsawyerx [...] gmail.com>
Date: Thu, 19 Jan 2017 17:36:17 -0700
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 3.2k
On 01/17/2017 02:52 PM, Leon Timmermans wrote: Show quoted text
> On Tue, Jan 17, 2017 at 9:10 PM, Sawyer X <xsawyerx@gmail.com > <mailto:xsawyerx@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:xsawyerx@gmail.com> > > <mailto:xsawyerx@gmail.com <mailto:xsawyerx@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.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 4.9k
On Fri, 20 Jan 2017 00:36:59 GMT, public@khwilliamson.com wrote: Show quoted text
> 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:xsawyerx@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:xsawyerx@gmail.com> > > > <mailto:xsawyerx@gmail.com <mailto:xsawyerx@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)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 5.9k
On Mon, 06 Feb 2017 08:23:25 -0800, jkeenan wrote: Show quoted text
> 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:xsawyerx@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:xsawyerx@gmail.com> > > > > <mailto:xsawyerx@gmail.com <mailto:xsawyerx@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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 433b
On Wed, 08 Feb 2017 17:18:13 GMT, khw wrote: [snip] Show quoted text
> 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)
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
To: James E Keenan via RT <perlbug-followup [...] perl.org>
Date: Mon, 20 Mar 2017 14:28:53 +0000
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 772b
On Wed, Feb 08, 2017 at 10:19:25AM -0800, James E Keenan via RT wrote: Show quoted text
> 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.
CC: perl5-porters [...] perl.org
Date: Mon, 27 Mar 2017 11:35:39 +0100
To: James E Keenan via RT <perlbug-followup [...] perl.org>
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 282b
On Mon, Mar 20, 2017 at 02:28:53PM +0000, Dave Mitchell wrote: Show quoted text
> 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"
To: James E Keenan via RT <perlbug-followup [...] perl.org>
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Date: Mon, 27 Mar 2017 11:37:41 +0100
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 420b
On Mon, Mar 20, 2017 at 02:28:53PM +0000, Dave Mitchell wrote: Show quoted text
> 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"
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 483b
On Mon, 27 Mar 2017 03:38:20 -0700, davem wrote: Show quoted text
> 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
RT-Send-CC: perl5-porters [...] perl.org
We decided to not revert; rejected -- Karl Williamson
From: Leon Timmermans <fawaka [...] gmail.com>
Date: Thu, 6 Apr 2017 02:41:22 +0200
CC: Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
To: perlbug <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.2k
On Wed, Feb 8, 2017 at 6:18 PM, Karl Williamson via RT <perlbug-followup@perl.org> wrote: Show quoted text
> > 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.
It seems that right now we're breaking autoconf by making this fatal. *Autoconf*. It has been fixed in their repository, but they haven't done a stable release in years. Think of that what you want, but there's a staggering amount of software depending on autoconf. I don't see how we can not revert this fatalization given these circumstances. The advantages are too theoretical to offset this very practical problem, and reverting would give us at least a year to deal with autotools' release inertia. Leon
From: Sawyer X <xsawyerx [...] gmail.com>
To: Leon Timmermans <fawaka [...] gmail.com>, perlbug <perlbug-followup [...] perl.org>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
CC: Perl5 Porters <perl5-porters [...] perl.org>
Date: Thu, 6 Apr 2017 19:52:47 +0200
Download (untitled) / with headers
text/plain 1.4k
On 04/06/2017 02:41 AM, Leon Timmermans wrote: Show quoted text
> On Wed, Feb 8, 2017 at 6:18 PM, Karl Williamson via RT > <perlbug-followup@perl.org> wrote:
>> 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.
> It seems that right now we're breaking autoconf by making this fatal. > *Autoconf*. It has been fixed in their repository, but they haven't > done a stable release in years. Think of that what you want, but > there's a staggering amount of software depending on autoconf. > > I don't see how we can not revert this fatalization given these > circumstances. The advantages are too theoretical to offset this very > practical problem, and reverting would give us at least a year to deal > with autotools' release inertia.
I agree. This leaves us little room but to simply revert this and manage a release of Autoconf before we revert it at the very least.
To: Sawyer X <xsawyerx [...] gmail.com>, Leon Timmermans <fawaka [...] gmail.com>, perlbug <perlbug-followup [...] perl.org>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Karl Williamson <public [...] khwilliamson.com>
Date: Thu, 6 Apr 2017 13:05:15 -0600
CC: Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.5k
On 4/6/2017 11:52 AM, Sawyer X wrote: Show quoted text
> > > On 04/06/2017 02:41 AM, Leon Timmermans wrote:
>> On Wed, Feb 8, 2017 at 6:18 PM, Karl Williamson via RT >> <perlbug-followup@perl.org> wrote:
>>> 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.
>> It seems that right now we're breaking autoconf by making this fatal. >> *Autoconf*. It has been fixed in their repository, but they haven't >> done a stable release in years. Think of that what you want, but >> there's a staggering amount of software depending on autoconf. >> >> I don't see how we can not revert this fatalization given these >> circumstances. The advantages are too theoretical to offset this very >> practical problem, and reverting would give us at least a year to deal >> with autotools' release inertia.
> > I agree. This leaves us little room but to simply revert this and manage > a release of Autoconf before we revert it at the very least. >
I have sent an email to the maintainers, asking for when they plan to release an update.
Date: Thu, 6 Apr 2017 13:26:08 -0600
CC: Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Karl Williamson <public [...] khwilliamson.com>
To: Sawyer X <xsawyerx [...] gmail.com>, Leon Timmermans <fawaka [...] gmail.com>, perlbug <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.8k
On 04/06/2017 01:05 PM, Karl Williamson wrote: Show quoted text
> On 4/6/2017 11:52 AM, Sawyer X wrote:
>> >> >> On 04/06/2017 02:41 AM, Leon Timmermans wrote:
>>> On Wed, Feb 8, 2017 at 6:18 PM, Karl Williamson via RT >>> <perlbug-followup@perl.org> wrote:
>>>> 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.
>>> It seems that right now we're breaking autoconf by making this fatal. >>> *Autoconf*. It has been fixed in their repository, but they haven't >>> done a stable release in years. Think of that what you want, but >>> there's a staggering amount of software depending on autoconf. >>> >>> I don't see how we can not revert this fatalization given these >>> circumstances. The advantages are too theoretical to offset this very >>> practical problem, and reverting would give us at least a year to deal >>> with autotools' release inertia.
>> >> I agree. This leaves us little room but to simply revert this and manage >> a release of Autoconf before we revert it at the very least. >>
> > I have sent an email to the maintainers, asking for when they plan to > release an update. >
I already received a response, which was effectively, "whenever I can get to it; didn't make it last December, when I hoped"
RT-Send-CC: perl5-porters [...] perl.org
Reopened -- Karl Williamson
Date: Thu, 6 Apr 2017 15:51:47 -0600
CC: perl5-porters [...] perl.org
To: perlbug-followup [...] perl.org
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 1019b
On 04/06/2017 02:36 PM, Karl Williamson via RT wrote: Show quoted text
> Reopened >
Think about the following a little before doing a knee-jerk "No". What if we put in a kludge so that it remained fatal except when compiling the exact single pattern that autoconf uses? It is /\${[^\}]*}/ Thus, when we are about to die, we check if the pattern attempting to be compiled is this exact one, and if so, merely warn. It is the one way I can think of that keeps us from being held hostage to this lackadaisical alien project for who knows how many more Decembers. What are the downsides? 1. It is inelegant 2. It is inelegant 3. It is inelegant ... n-1. It is inelegant n. Any other code that has this exact pattern would compile instead of not. But so what? This particular pattern would not be affected by any of the proposed changes that making this illegal would allow. They are, so far, a. to be able to say \w{something} b. to be able to have white space and a missing lower bound in {...} quantifiers.
Date: Thu, 6 Apr 2017 16:53:34 -0600
CC: perl5-porters [...] perl.org
To: perlbug-followup [...] perl.org
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 1.8k
On 04/06/2017 03:51 PM, Karl Williamson wrote: Show quoted text
> On 04/06/2017 02:36 PM, Karl Williamson via RT wrote:
>> Reopened >>
> > Think about the following a little before doing a knee-jerk "No". > > What if we put in a kludge so that it remained fatal except when > compiling the exact single pattern that autoconf uses? It is > > /\${[^\}]*}/ > > Thus, when we are about to die, we check if the pattern attempting to be > compiled is this exact one, and if so, merely warn. > > It is the one way I can think of that keeps us from being held hostage > to this lackadaisical alien project for who knows how many more Decembers. > > What are the downsides? > > 1. It is inelegant > 2. It is inelegant > 3. It is inelegant > ... > n-1. It is inelegant > n. Any other code that has this exact pattern would compile instead of > not. But so what? This particular pattern would not be affected by any > of the proposed changes that making this illegal would allow. They are, > so far, > > a. to be able to say \w{something} > b. to be able to have white space and a missing lower bound in {...} > quantifiers. >
I now offer a somewhat less kludgy idea. Change the code so that at the point of raising the fatal message, it first looks at the current context. If the left brace does not conflict with ideas we have as to how we could use it not-literally, then don't die but instead raise the warning. This is more general than just the autoconf pattern, and so there are many more possible patterns that we would not die on, and this would not restrict our ability to make the currently foreseeable changes to left brace handling. So if there are other things besides autoconf we haven't yet found, this would lessen the possibility that they would cause a problem. Besides tests and pod, the only changes needed would be to insert these tests just before we currently die.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1000b
On Thu, 06 Apr 2017 15:55:14 -0700, public@khwilliamson.com wrote: Show quoted text
> I now offer a somewhat less kludgy idea. Change the code so that at the > point of raising the fatal message, it first looks at the current > context. If the left brace does not conflict with ideas we have as to > how we could use it not-literally, then don't die but instead raise the > warning.
Much better. “Unescaped left brace may conflict with future pattern syntax” or suchlike. Show quoted text
> > This is more general than just the autoconf pattern, and so there are > many more possible patterns that we would not die on, and this would not > restrict our ability to make the currently foreseeable changes to left > brace handling. So if there are other things besides autoconf we > haven't yet found, this would lessen the possibility that they would > cause a problem. > > Besides tests and pod, the only changes needed would be to insert these > tests just before we currently die. >
-- Father Chrysostomos
CC: perl5-porters [...] perl.org
Date: Fri, 7 Apr 2017 20:07:54 +0200
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
To: perlbug-followup [...] perl.org
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 624b
On 04/07/2017 02:46 AM, Father Chrysostomos via RT wrote: Show quoted text
> On Thu, 06 Apr 2017 15:55:14 -0700, public@khwilliamson.com wrote:
>> I now offer a somewhat less kludgy idea. Change the code so that at the >> point of raising the fatal message, it first looks at the current >> context. If the left brace does not conflict with ideas we have as to >> how we could use it not-literally, then don't die but instead raise the >> warning.
> Much better. > > “Unescaped left brace may conflict with future pattern syntax” or suchlike.
Not a bad idea, but we're pretty far in the cycle to test this change out, I think.
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Date: Sat, 8 Apr 2017 06:21:54 +1200
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Kent Fredric <kentfredric [...] gmail.com>
To: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 481b
On 8 April 2017 at 06:07, Sawyer X <xsawyerx@gmail.com> wrote: Show quoted text
> Not a bad idea, but we're pretty far in the cycle to test this change > out, I think.
Yeah, the cleverer the solution, the more time we need to make sure we didn't introduce additional bugs in the cleverness. Which in practice means this late, without additional test cycles, this change would be worse than either choice of "leave it in" or "take it out". -- Kent KENTNL - https://metacpan.org/author/KENTNL
To: Kent Fredric <kentfredric [...] gmail.com>, Sawyer X <xsawyerx [...] gmail.com>
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Date: Sat, 8 Apr 2017 20:51:02 -0600
Download (untitled) / with headers
text/plain 1.5k
On 04/07/2017 12:21 PM, Kent Fredric wrote: Show quoted text
> On 8 April 2017 at 06:07, Sawyer X <xsawyerx@gmail.com> wrote:
>> Not a bad idea, but we're pretty far in the cycle to test this change >> out, I think.
> > > Yeah, the cleverer the solution, the more time we need to make sure we > didn't introduce additional bugs in the cleverness. > > Which in practice means this late, without additional test cycles, > this change would be worse than either choice of "leave it in" or > "take it out". >
I think people should be aware of the full consequences of this. It is not just a simple matter of reverting this patch. Code has marched on. In particular, you may recall that I missed some cases where the deprecation should have been output, and code to output these was added after this patch, and so presumes that these cases are fatal. If I change the patch to just silently continue, the other code fails to output a warning on some of the cases covered by this. If I instead change it to output a warning, some cases will have 2 warnings output. And cleverness is required to fix that. We could say that at this stage in development, that we can live with 2 warnings. But the other warning explicitly says it will be made fatal in 5.30. Part of the reason to make these cases fatal now, was so that in 5.28, we could implement some of the extensions made feasible by this. Having 2 warnings closes the door on that possibility. The solution that requires the least cleverness is my original kludge, to simply make /\${[^\}]*}/ non-fatal. It's trivial to do this, and keep it to a single warning
Date: Sun, 9 Apr 2017 20:01:26 +0200
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
To: Karl Williamson <public [...] khwilliamson.com>, Kent Fredric <kentfredric [...] gmail.com>
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 2.2k
On 04/09/2017 04:51 AM, Karl Williamson wrote: Show quoted text
> On 04/07/2017 12:21 PM, Kent Fredric wrote:
>> On 8 April 2017 at 06:07, Sawyer X <xsawyerx@gmail.com> wrote:
>>> Not a bad idea, but we're pretty far in the cycle to test this change >>> out, I think.
>> >> >> Yeah, the cleverer the solution, the more time we need to make sure we >> didn't introduce additional bugs in the cleverness. >> >> Which in practice means this late, without additional test cycles, >> this change would be worse than either choice of "leave it in" or >> "take it out". >>
> > I think people should be aware of the full consequences of this. > > It is not just a simple matter of reverting this patch. Code has > marched on. In particular, you may recall that I missed some cases > where the deprecation should have been output, and code to output > these was added after this patch, and so presumes that these cases are > fatal. > > If I change the patch to just silently continue, the other code fails > to output a warning on some of the cases covered by this. If I > instead change it to output a warning, some cases will have 2 warnings > output. And cleverness is required to fix that. We could say that at > this stage in development, that we can live with 2 warnings. But the > other warning explicitly says it will be made fatal in 5.30. Part of > the reason to make these cases fatal now, was so that in 5.28, we > could implement some of the extensions made feasible by this. Having > 2 warnings closes the door on that possibility. > > The solution that requires the least cleverness is my original kludge, > to simply make > > /\${[^\}]*}/ > > non-fatal. It's trivial to do this, and keep it to a single warning
To be honest, I'm a bit concerned about introducing this kludge. The questions that jump to mind are: * Is there a chance we would misrecognize[1] the context in XS code or core code? (I'm thinking of the oneliner in eval in heredoc in regex s///e and such.) * What happens if we misidentify this context? Will it crash? If it does, will this error message be useful? (If we can move the warning to 5.32, why would the deprecation warning be a show-stopper?) If we go with the kludge, at the very least it would require having another dev release. [1] This is a real word, I checked.
Date: Sun, 9 Apr 2017 22:20:29 -0600
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Karl Williamson <public [...] khwilliamson.com>
To: Sawyer X <xsawyerx [...] gmail.com>, Kent Fredric <kentfredric [...] gmail.com>
Download (untitled) / with headers
text/plain 4.1k
On 04/09/2017 12:01 PM, Sawyer X wrote: Show quoted text
> > On 04/09/2017 04:51 AM, Karl Williamson wrote:
>> On 04/07/2017 12:21 PM, Kent Fredric wrote:
>>> On 8 April 2017 at 06:07, Sawyer X <xsawyerx@gmail.com> wrote:
>>>> Not a bad idea, but we're pretty far in the cycle to test this change >>>> out, I think.
>>> >>> >>> Yeah, the cleverer the solution, the more time we need to make sure we >>> didn't introduce additional bugs in the cleverness. >>> >>> Which in practice means this late, without additional test cycles, >>> this change would be worse than either choice of "leave it in" or >>> "take it out". >>>
>> >> I think people should be aware of the full consequences of this. >> >> It is not just a simple matter of reverting this patch. Code has >> marched on. In particular, you may recall that I missed some cases >> where the deprecation should have been output, and code to output >> these was added after this patch, and so presumes that these cases are >> fatal. >> >> If I change the patch to just silently continue, the other code fails >> to output a warning on some of the cases covered by this. If I >> instead change it to output a warning, some cases will have 2 warnings >> output. And cleverness is required to fix that. We could say that at >> this stage in development, that we can live with 2 warnings. But the >> other warning explicitly says it will be made fatal in 5.30. Part of >> the reason to make these cases fatal now, was so that in 5.28, we >> could implement some of the extensions made feasible by this. Having >> 2 warnings closes the door on that possibility. >> >> The solution that requires the least cleverness is my original kludge, >> to simply make >> >> /\${[^\}]*}/ >> >> non-fatal. It's trivial to do this, and keep it to a single warning
> > To be honest, I'm a bit concerned about introducing this kludge. The > questions that jump to mind are: > > * Is there a chance we would misrecognize[1] the context in XS code or > core code? (I'm thinking of the oneliner in eval in heredoc in regex > s///e and such.) > * What happens if we misidentify this context? Will it crash? If it > does, will this error message be useful?
I don't think you understand the proposal. The goal is to work around autoconf's failure to release a fix in 4 years, so far. In 5.25, autoconf won't compile because a deprecation is now made fatal. The issue is a single pattern in autoconf. All we would be doing is, if we are about to die, to first look to see if it is that exact pattern, and if so, warn, don't die. Thus autoconf would work as it does in 5.24. And it would continue to do so as long as it doesn't get upgraded. As soon as it is upgraded, the already-commited fix in its repository would cause it to avoid this issue entirely. Any other code anywhere that had that exact same pattern would also warn not die, just as what it does in 5.24. And there wouldn't be a problem with that, as the pattern does not use '{' in a way that would conflict with anything currently planned by perl. So we are removing a "crash", not adding one. "Misrecognizing" something other than this pattern as this pattern isn't a problem, because if we did, we give them the same behavior as has existed in 5.24 and earlier. "Misrecognizing" this pattern for something else would cause a problem for autoconf. But we would verify, before release, that it actually did solve the autoconf problem. Remember, we are looking at working around a single line in the current version of autoconf; nothing more. Show quoted text
> > (If we can move the warning to 5.32, why would the deprecation warning > be a show-stopper?)
I don't understand the above at all. I wonder if '32' is a typo. My goal is to get something in 5.28. We can't have two messages displayed with one saying 28, and the other 30. They would both have to say the later release: 30; and that means nothing could get added in 28. Show quoted text
> > If we go with the kludge, at the very least it would require having > another dev release.
I mostly agree, and I thought that was already in the plans because of @INC. But it's not clear to me that attempting a reversion wouldn't also require such a release. Show quoted text
> > [1] This is a real word, I checked. >
Don't misunderestimate.
Date: Mon, 10 Apr 2017 12:21:18 +0100
CC: Sawyer X <xsawyerx [...] gmail.com>, Kent Fredric <kentfredric [...] gmail.com>, Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
To: Karl Williamson <public [...] khwilliamson.com>
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 346b
Show quoted text
> > > The solution that requires the least cleverness is my original kludge, > > > to simply make > > > > > > /\${[^\}]*}/ > > > > > > non-fatal. It's trivial to do this, and keep it to a single warning
+1 -- "There's something wrong with our bloody ships today, Chatfield." -- Admiral Beatty at the Battle of Jutland, 31st May 1916.
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Karl Williamson <public [...] khwilliamson.com>
To: Dave Mitchell <davem [...] iabyn.com>
CC: Sawyer X <xsawyerx [...] gmail.com>, Kent Fredric <kentfredric [...] gmail.com>, Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Date: Mon, 10 Apr 2017 11:16:06 -0600
Download (untitled) / with headers
text/plain 383b
On 04/10/2017 05:21 AM, Dave Mitchell wrote: Show quoted text
>>>> The solution that requires the least cleverness is my original kludge, >>>> to simply make >>>> >>>> /\${[^\}]*}/ >>>> >>>> non-fatal. It's trivial to do this, and keep it to a single warning
> > +1 >
To show how much code is involved in doing this, a minimal patch is attached, without fixing the indent nor comments nor tests.

Message body is not shown because sender requested not to inline it.

From: Sawyer X <xsawyerx [...] gmail.com>
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Date: Wed, 12 Apr 2017 11:04:04 +0200
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
To: Karl Williamson <public [...] khwilliamson.com>, Kent Fredric <kentfredric [...] gmail.com>
Download (untitled) / with headers
text/plain 4.6k
On 04/10/2017 06:20 AM, Karl Williamson wrote: Show quoted text
> On 04/09/2017 12:01 PM, Sawyer X wrote:
>> >> On 04/09/2017 04:51 AM, Karl Williamson wrote:
>>> On 04/07/2017 12:21 PM, Kent Fredric wrote:
>>>> On 8 April 2017 at 06:07, Sawyer X <xsawyerx@gmail.com> wrote:
>>>>> Not a bad idea, but we're pretty far in the cycle to test this change >>>>> out, I think.
>>>> >>>> >>>> Yeah, the cleverer the solution, the more time we need to make sure we >>>> didn't introduce additional bugs in the cleverness. >>>> >>>> Which in practice means this late, without additional test cycles, >>>> this change would be worse than either choice of "leave it in" or >>>> "take it out". >>>>
>>> >>> I think people should be aware of the full consequences of this. >>> >>> It is not just a simple matter of reverting this patch. Code has >>> marched on. In particular, you may recall that I missed some cases >>> where the deprecation should have been output, and code to output >>> these was added after this patch, and so presumes that these cases are >>> fatal. >>> >>> If I change the patch to just silently continue, the other code fails >>> to output a warning on some of the cases covered by this. If I >>> instead change it to output a warning, some cases will have 2 warnings >>> output. And cleverness is required to fix that. We could say that at >>> this stage in development, that we can live with 2 warnings. But the >>> other warning explicitly says it will be made fatal in 5.30. Part of >>> the reason to make these cases fatal now, was so that in 5.28, we >>> could implement some of the extensions made feasible by this. Having >>> 2 warnings closes the door on that possibility. >>> >>> The solution that requires the least cleverness is my original kludge, >>> to simply make >>> >>> /\${[^\}]*}/ >>> >>> non-fatal. It's trivial to do this, and keep it to a single warning
>> >> To be honest, I'm a bit concerned about introducing this kludge. The >> questions that jump to mind are: >> >> * Is there a chance we would misrecognize[1] the context in XS code or >> core code? (I'm thinking of the oneliner in eval in heredoc in regex >> s///e and such.) >> * What happens if we misidentify this context? Will it crash? If it >> does, will this error message be useful?
> > I don't think you understand the proposal. The goal is to work around > autoconf's failure to release a fix in 4 years, so far. In 5.25, > autoconf won't compile because a deprecation is now made fatal. The > issue is a single pattern in autoconf. All we would be doing is, if > we are about to die, to first look to see if it is that exact pattern, > and if so, warn, don't die. Thus autoconf would work as it does in > 5.24. And it would continue to do so as long as it doesn't get > upgraded. As soon as it is upgraded, the already-commited fix in its > repository would cause it to avoid this issue entirely. > > Any other code anywhere that had that exact same pattern would also > warn not die, just as what it does in 5.24. And there wouldn't be a > problem with that, as the pattern does not use '{' in a way that would > conflict with anything currently planned by perl. So we are removing > a "crash", not adding one. > > "Misrecognizing" something other than this pattern as this pattern > isn't a problem, because if we did, we give them the same behavior as > has existed in 5.24 and earlier. > > "Misrecognizing" this pattern for something else would cause a problem > for autoconf. But we would verify, before release, that it actually > did solve the autoconf problem. Remember, we are looking at working > around a single line in the current version of autoconf; nothing more.
Fair enough. (I have read dutifully, I just don't have much to add and I don't want to just hash it.) Show quoted text
>> >> (If we can move the warning to 5.32, why would the deprecation warning >> be a show-stopper?)
> > I don't understand the above at all. I wonder if '32' is a typo. My > goal is to get something in 5.28. We can't have two messages > displayed with one saying 28, and the other 30. They would both have > to say the later release: 30; and that means nothing could get added > in 28.
I misread when you wrote 5.30 above. Added another stable and got 32. Did I mention I'm dyslexic? :) Show quoted text
>> >> If we go with the kludge, at the very least it would require having >> another dev release.
> > I mostly agree, and I thought that was already in the plans because of > @INC. But it's not clear to me that attempting a reversion wouldn't > also require such a release.
We had already released another dev for the @INC change. Several have asked for another dev release in order to clear out more kinks in CPAN. Show quoted text
>
>> >> [1] This is a real word, I checked. >>
> > Don't misunderestimate.
<3
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Wed, 12 Apr 2017 09:06:08 GMT, xsawyerx@gmail.com wrote: Show quoted text
> > > On 04/10/2017 06:20 AM, Karl Williamson wrote:
> > On 04/09/2017 12:01 PM, Sawyer X wrote:
[snip] Show quoted text
> >> > >> If we go with the kludge, at the very least it would require having > >> another dev release.
> > > > I mostly agree, and I thought that was already in the plans because of > > @INC. But it's not clear to me that attempting a reversion wouldn't > > also require such a release.
> > We had already released another dev for the @INC change. Several have > asked for another dev release in order to clear out more kinks in CPAN. >
Some data ... I did a local checkout of the smoke-me/khw-lbrace branch and yesterday ran it through a "CPAN river" test similar to what I have been reporting on perl.qa for the no-dot-by-default-in-@INC changes. That is, I * set PERL_USE_UNSAFE_INC to 1 (because we're not interested in no-dot failures for the purpose of this branch); * created a list of all CPAN distributions in dependency order; * selected a subset of that list -- in this case, the top 5000 entries; * ran that list through a single 'cpanm' call. Analysis of the 'cpanm' build.log showed no failures due to "Unescaped left brace in regex". To be sure, there are limitations to this approach. A distro which depends on a distro which fails to install for reasons other than the one under consideration cannot be tested and so may still suffer from the problem under consideration. Data available. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
Date: Sun, 16 Apr 2017 21:22:55 +0100
CC: Sawyer X <xsawyerx [...] gmail.com>, Kent Fredric <kentfredric [...] gmail.com>, Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
To: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 653b
On Mon, Apr 10, 2017 at 11:16:06AM -0600, Karl Williamson wrote: Show quoted text
> On 04/10/2017 05:21 AM, Dave Mitchell wrote:
> > > > > The solution that requires the least cleverness is my original kludge, > > > > > to simply make > > > > > > > > > > /\${[^\}]*}/ > > > > > > > > > > non-fatal. It's trivial to do this, and keep it to a single warning
> > > > +1 > >
> > To show how much code is involved in doing this, a minimal patch is > attached, without fixing the indent nor comments nor tests.
I *think* we're agreed that this should happen. Will you apply this now? -- Overhead, without any fuss, the stars were going out. -- Arthur C Clarke
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 744b
On Sun, 16 Apr 2017 13:23:50 -0700, davem wrote: Show quoted text
> On Mon, Apr 10, 2017 at 11:16:06AM -0600, Karl Williamson wrote:
> > On 04/10/2017 05:21 AM, Dave Mitchell wrote:
> > > > > > The solution that requires the least cleverness is my > > > > > > original kludge, > > > > > > to simply make > > > > > > > > > > > > /\${[^\}]*}/ > > > > > > > > > > > > non-fatal. It's trivial to do this, and keep it to a single > > > > > > warning
> > > > > > +1 > > >
> > > > To show how much code is involved in doing this, a minimal patch is > > attached, without fixing the indent nor comments nor tests.
> > I *think* we're agreed that this should happen. Will you apply this > now?
In case this helps, it gets a +1 from me, too. -- Father Chrysostomos
To: perlbug-followup [...] perl.org
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Date: Sun, 16 Apr 2017 21:52:19 -0600
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 805b
On 04/16/2017 02:40 PM, Father Chrysostomos via RT wrote: Show quoted text
> On Sun, 16 Apr 2017 13:23:50 -0700, davem wrote:
>> On Mon, Apr 10, 2017 at 11:16:06AM -0600, Karl Williamson wrote:
>>> On 04/10/2017 05:21 AM, Dave Mitchell wrote:
>>>>>>> The solution that requires the least cleverness is my >>>>>>> original kludge, >>>>>>> to simply make >>>>>>> >>>>>>> /\${[^\}]*}/ >>>>>>> >>>>>>> non-fatal. It's trivial to do this, and keep it to a single >>>>>>> warning
>>>> >>>> +1 >>>>
>>> >>> To show how much code is involved in doing this, a minimal patch is >>> attached, without fixing the indent nor comments nor tests.
>> >> I *think* we're agreed that this should happen. Will you apply this >> now?
> > In case this helps, it gets a +1 from me, too. >
I haven't heard a clear go-ahead from the pumpking.
CC: Kent Fredric <kentfredric [...] gmail.com>, Sawyer X <xsawyerx [...] gmail.com>, Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Date: Mon, 17 Apr 2017 16:18:40 +0200
To: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 1.5k
On Sun, Apr 9, 2017 at 4:51 AM, Karl Williamson <public@khwilliamson.com> wrote: Show quoted text
> I think people should be aware of the full consequences of this. > > It is not just a simple matter of reverting this patch. Code has marched > on. In particular, you may recall that I missed some cases where the > deprecation should have been output, and code to output these was added > after this patch, and so presumes that these cases are fatal. > > If I change the patch to just silently continue, the other code fails to > output a warning on some of the cases covered by this. If I instead change > it to output a warning, some cases will have 2 warnings output. And > cleverness is required to fix that. We could say that at this stage in > development, that we can live with 2 warnings. But the other warning > explicitly says it will be made fatal in 5.30. Part of the reason to make > these cases fatal now, was so that in 5.28, we could implement some of the > extensions made feasible by this. Having 2 warnings closes the door on that > possibility. > > The solution that requires the least cleverness is my original kludge, to > simply make > > /\${[^\}]*}/ > > non-fatal. It's trivial to do this, and keep it to a single warning
I do think this provides a lesson for the future. It's generally a better idea to leave breaking changes like this in a revertible state until the dust has settled down. Quite frankly, if we can miss a target the size of autoconf, one starts to wonder what else did we miss. Not knowing that answer makes a workaround that only solves autoconf a rather uncertain solution. Leon
Date: Mon, 17 Apr 2017 11:22:01 -0400
To: perl5-porters [...] perl.org
From: James E Keenan <jkeenan [...] pobox.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Download (untitled) / with headers
text/plain 1.3k
On 04/17/2017 10:18 AM, Leon Timmermans wrote: Show quoted text
> > Quite frankly, if we can miss a target the size of autoconf, one > starts to wonder what else did we miss. Not knowing that answer makes > a workaround that only solves autoconf a rather uncertain solution. >
Our primary codebase for testing is the core distribution's internal test suite. Our secondary codebase for testing is CPAN. Up until now, those have generally been sufficient. However, going forward -- particularly with respect to deprecations and subsequent fatalizations -- we need to test against a tertiary codebase. That tertiary codebase would be the "important" executables written in Perl and dependent upon the "system perl" or "vendor perl" in prominent open source software distributions. Off the top of my head, I'd say such software distributions would include: Linux: Debian Ubuntu RedHat Gentoo BSD: FreeBSD OpenBSD We would have to work with the people identified as "Perl maintainers" for those distributions -- many of whom we know already and who have committed code to the core -- to identify programs like autoconf that are vulnerable to deprecations and fatalizations. Then, when a deprecation is proposed, we'd have to smoke it against those programs' own test suites. Whether and when we fatalize some feature would depend on feedback from those maintainers. Thank you very much. Jim Keenan
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
To: Karl Williamson <public [...] khwilliamson.com>, perlbug-followup [...] perl.org
CC: perl5-porters [...] perl.org
Date: Mon, 17 Apr 2017 19:04:20 +0200
Download (untitled) / with headers
text/plain 894b
On 04/17/2017 05:52 AM, Karl Williamson wrote: Show quoted text
> On 04/16/2017 02:40 PM, Father Chrysostomos via RT wrote:
>> On Sun, 16 Apr 2017 13:23:50 -0700, davem wrote:
>>> On Mon, Apr 10, 2017 at 11:16:06AM -0600, Karl Williamson wrote:
>>>> On 04/10/2017 05:21 AM, Dave Mitchell wrote:
>>>>>>>> The solution that requires the least cleverness is my >>>>>>>> original kludge, >>>>>>>> to simply make >>>>>>>> >>>>>>>> /\${[^\}]*}/ >>>>>>>> >>>>>>>> non-fatal. It's trivial to do this, and keep it to a single >>>>>>>> warning
>>>>> >>>>> +1 >>>>>
>>>> >>>> To show how much code is involved in doing this, a minimal patch is >>>> attached, without fixing the indent nor comments nor tests.
>>> >>> I *think* we're agreed that this should happen. Will you apply this >>> now?
>> >> In case this helps, it gets a +1 from me, too. >>
> > I haven't heard a clear go-ahead from the pumpking.
Sorry. +1!
From: Graham Knop <haarg [...] haarg.org>
To: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
Date: Mon, 17 Apr 2017 20:57:54 +0200
CC: Karl Williamson <public [...] khwilliamson.com>, Kent Fredric <kentfredric [...] gmail.com>, Sawyer X <xsawyerx [...] gmail.com>, Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.7k
On Mon, Apr 17, 2017 at 4:18 PM, Leon Timmermans <fawaka@gmail.com> wrote: Show quoted text
> On Sun, Apr 9, 2017 at 4:51 AM, Karl Williamson <public@khwilliamson.com> wrote:
>> I think people should be aware of the full consequences of this. >> >> It is not just a simple matter of reverting this patch. Code has marched >> on. In particular, you may recall that I missed some cases where the >> deprecation should have been output, and code to output these was added >> after this patch, and so presumes that these cases are fatal. >> >> If I change the patch to just silently continue, the other code fails to >> output a warning on some of the cases covered by this. If I instead change >> it to output a warning, some cases will have 2 warnings output. And >> cleverness is required to fix that. We could say that at this stage in >> development, that we can live with 2 warnings. But the other warning >> explicitly says it will be made fatal in 5.30. Part of the reason to make >> these cases fatal now, was so that in 5.28, we could implement some of the >> extensions made feasible by this. Having 2 warnings closes the door on that >> possibility. >> >> The solution that requires the least cleverness is my original kludge, to >> simply make >> >> /\${[^\}]*}/ >> >> non-fatal. It's trivial to do this, and keep it to a single warning
> > I do think this provides a lesson for the future. It's generally a > better idea to leave breaking changes like this in a revertible state > until the dust has settled down. > > Quite frankly, if we can miss a target the size of autoconf, one > starts to wonder what else did we miss. Not knowing that answer makes > a workaround that only solves autoconf a rather uncertain solution.
Another thing we missed is the go compiler: https://github.com/golang/go/issues/20007
To: Sawyer X <xsawyerx [...] gmail.com>, perlbug-followup [...] perl.org
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Karl Williamson <public [...] khwilliamson.com>
Date: Mon, 17 Apr 2017 19:32:10 -0600
CC: perl5-porters [...] perl.org
On 4/17/2017 11:04 AM, Sawyer X wrote: Show quoted text
> > > On 04/17/2017 05:52 AM, Karl Williamson wrote:
>> On 04/16/2017 02:40 PM, Father Chrysostomos via RT wrote:
>>> On Sun, 16 Apr 2017 13:23:50 -0700, davem wrote:
>>>> On Mon, Apr 10, 2017 at 11:16:06AM -0600, Karl Williamson wrote:
>>>>> On 04/10/2017 05:21 AM, Dave Mitchell wrote:
>>>>>>>>> The solution that requires the least cleverness is my >>>>>>>>> original kludge, >>>>>>>>> to simply make >>>>>>>>> >>>>>>>>> /\${[^\}]*}/ >>>>>>>>> >>>>>>>>> non-fatal. It's trivial to do this, and keep it to a single >>>>>>>>> warning
>>>>>> >>>>>> +1 >>>>>>
>>>>> >>>>> To show how much code is involved in doing this, a minimal patch is >>>>> attached, without fixing the indent nor comments nor tests.
>>>> >>>> I *think* we're agreed that this should happen. Will you apply this >>>> now?
>>> >>> In case this helps, it gets a +1 from me, too. >>>
>> >> I haven't heard a clear go-ahead from the pumpking.
> > Sorry. +1! > >
Now pushed as 7335cb814c19345052a23bc4462c701ce734e6c5
To: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #130497] Revert "Unescaped left brace in regex" fatality
From: Karl Williamson <public [...] khwilliamson.com>
CC: Kent Fredric <kentfredric [...] gmail.com>, Sawyer X <xsawyerx [...] gmail.com>, Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Date: Mon, 17 Apr 2017 19:36:12 -0600
Download (untitled) / with headers
text/plain 1.7k
On 4/17/2017 8:18 AM, Leon Timmermans wrote: Show quoted text
> On Sun, Apr 9, 2017 at 4:51 AM, Karl Williamson <public@khwilliamson.com> wrote:
>> I think people should be aware of the full consequences of this. >> >> It is not just a simple matter of reverting this patch. Code has marched >> on. In particular, you may recall that I missed some cases where the >> deprecation should have been output, and code to output these was added >> after this patch, and so presumes that these cases are fatal. >> >> If I change the patch to just silently continue, the other code fails to >> output a warning on some of the cases covered by this. If I instead change >> it to output a warning, some cases will have 2 warnings output. And >> cleverness is required to fix that. We could say that at this stage in >> development, that we can live with 2 warnings. But the other warning >> explicitly says it will be made fatal in 5.30. Part of the reason to make >> these cases fatal now, was so that in 5.28, we could implement some of the >> extensions made feasible by this. Having 2 warnings closes the door on that >> possibility. >> >> The solution that requires the least cleverness is my original kludge, to >> simply make >> >> /\${[^\}]*}/ >> >> non-fatal. It's trivial to do this, and keep it to a single warning
> > I do think this provides a lesson for the future. It's generally a > better idea to leave breaking changes like this in a revertible state > until the dust has settled down.
This is a worthwhile goal, but not really achievable. Such changes should (as this one was) be done very early in the cycle, to flush out problems. At that time, its quite likely that there will be unforeseen changes to come. In this case, the conflict with Autoconf wasn't found until after the freeze.


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

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