Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Revert "Unescaped left brace in regex" fatality #15792

Closed
p5pRT opened this issue Jan 3, 2017 · 79 comments
Closed

Revert "Unescaped left brace in regex" fatality #15792

p5pRT opened this issue Jan 3, 2017 · 79 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 3, 2017

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

Searchable as RT130497$

@p5pRT
Copy link
Author

p5pRT commented Jan 3, 2017

From @andk

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

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

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

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

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

Is it still your expectation?

  > Yes

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

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

--
Perlin' not only for Berlin;)

perl -V


Summary of my perl5 (revision 5 version 25 subversion 9) configuration​:
  Commit id​: 66b0926
  Platform​:
  osname=linux
  osvers=4.8.0-2-amd64
  archname=x86_64-linux
  uname='linux k93msid 4.8.0-2-amd64 #1 smp debian 4.8.11-1 (2016-12-02) x86_64 gnulinux '
  config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.25.8-146-g66b092637d/89ad -Dmyhostname=k93msid -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Dlibswanted=cl pthread socket inet nsl gdbm dbm malloc dl ld sun m crypt sec util c cposix posix ucb BSD gdbm_compat -Uuseithreads -Uuselongdouble -DDEBUGGING=-g'
  hint=recommended
  useposix=true
  d_sigaction=define
  useithreads=undef
  usemultiplicity=undef
  use64bitint=define
  use64bitall=define
  uselongdouble=undef
  usemymalloc=n
  bincompat5005=undef
  Compiler​:
  cc='cc'
  ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
  optimize='-O2 -g'
  cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
  ccversion=''
  gccversion='6.2.1 20161124'
  gccosandvers=''
  intsize=4
  longsize=8
  ptrsize=8
  doublesize=8
  byteorder=12345678
  doublekind=3
  d_longlong=define
  longlongsize=8
  d_longdbl=define
  longdblsize=16
  longdblkind=3
  ivtype='long'
  ivsize=8
  nvtype='double'
  nvsize=8
  Off_t='off_t'
  lseeksize=8
  alignbytes=8
  prototype=define
  Linker and Libraries​:
  ld='cc'
  ldflags =' -fstack-protector-strong -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
  libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.24.so
  so=so
  useshrplib=false
  libperl=libperl.a
  gnulibc_version='2.24'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs
  dlext=so
  d_dlsymun=undef
  ccdlflags='-Wl,-E'
  cccdlflags='-fPIC'
  lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector-strong'

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

@p5pRT
Copy link
Author

p5pRT commented Jan 3, 2017

From @jkeenan

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

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

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

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

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

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

Is it still your expectation?

Yes

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

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

Can you identify those distributions?

Thank you very much.

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

@p5pRT
Copy link
Author

p5pRT commented Jan 3, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Jan 4, 2017

From @andk

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

  > Can you identify those distributions?

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

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

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

Thanks,
--
andreas

@p5pRT
Copy link
Author

p5pRT commented Jan 4, 2017

From @jkeenan

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

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

Can you identify those distributions?

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

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

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

Thanks,

Andreas, thanks for providing that list.

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

So the questions we face are​:

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

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

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

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

@p5pRT
Copy link
Author

p5pRT commented Jan 4, 2017

@p5pRT
Copy link
Author

p5pRT commented Jan 4, 2017

From @jkeenan

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

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

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

Can you identify those distributions?

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

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

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

Thanks,

Andreas, thanks for providing that list.

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

So the questions we face are​:

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

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

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

Thank you very much.

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

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

@p5pRT
Copy link
Author

p5pRT commented Jan 4, 2017

From @jkeenan

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

@p5pRT
Copy link
Author

p5pRT commented Jan 4, 2017

From [Unknown Contact. See original ticket]

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

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

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

Can you identify those distributions?

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

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

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

Thanks,

Andreas, thanks for providing that list.

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

So the questions we face are​:

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

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

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

Thank you very much.

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

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

@p5pRT
Copy link
Author

p5pRT commented Jan 4, 2017

From @jkeenan

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

Andreas, thanks for providing that list.

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

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

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

@p5pRT
Copy link
Author

p5pRT commented Jan 4, 2017

From cpan@zoffix.com

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

@p5pRT
Copy link
Author

p5pRT commented Jan 4, 2017

From [Unknown Contact. See original ticket]

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

@p5pRT
Copy link
Author

p5pRT commented Jan 5, 2017

From @khwilliamson

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

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

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

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

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

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

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

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

Thank you very much.

@p5pRT
Copy link
Author

p5pRT commented Jan 5, 2017

From @jkeenan

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

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

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

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

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

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

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

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

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

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

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

Thank you very much.

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

@p5pRT
Copy link
Author

p5pRT commented Jan 5, 2017

From @jkeenan

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

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

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

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

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

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

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

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

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

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

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

Thank you very much.

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

@p5pRT
Copy link
Author

p5pRT commented Jan 5, 2017

From @jkeenan

This is a bug report for​:

__________

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

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

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

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

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

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

Thank you very much.

@p5pRT
Copy link
Author

p5pRT commented Jan 5, 2017

From @jkeenan

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

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

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

| ZOFFIX/App-ZofCMS-1.001006 | 1
|
| |

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

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

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

@p5pRT
Copy link
Author

p5pRT commented Jan 6, 2017

From @xsawyerx

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

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

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

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

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

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

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

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

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

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

@p5pRT
Copy link
Author

p5pRT commented Jan 6, 2017

From @xsawyerx

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

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

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

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

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

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

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

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

@p5pRT
Copy link
Author

p5pRT commented Jan 6, 2017

From @xsawyerx

# This is a bug report for​:

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

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

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

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

Thanks!

@p5pRT
Copy link
Author

p5pRT commented Jan 6, 2017

From @jkeenan

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

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

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

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

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

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

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

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

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

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

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

Thank you very much.

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

@p5pRT
Copy link
Author

p5pRT commented Jan 6, 2017

From @jkeenan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thank you very much.

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

@p5pRT
Copy link
Author

p5pRT commented Jan 9, 2017

From @xsawyerx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@p5pRT
Copy link
Author

p5pRT commented Jan 9, 2017

From @xsawyerx

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

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

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

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

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

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

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

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

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

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

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

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

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

@p5pRT
Copy link
Author

p5pRT commented Jan 9, 2017

From @Leont

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

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

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

Leon

@p5pRT
Copy link
Author

p5pRT commented Jan 10, 2017

From @xsawyerx

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

On Fri, Jan 6, 2017 at 2​:42 PM, James E Keenan via RT
<perlbug-followup@​perl.org <mailto​: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?

@p5pRT
Copy link
Author

p5pRT commented Jan 10, 2017

From @Leont

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

@p5pRT
Copy link
Author

p5pRT commented Jan 10, 2017

From @jkeenan

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

On Tue, Jan 10, 2017 at 12​:26 PM, Sawyer X <xsawyerx@​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)

@p5pRT
Copy link
Author

p5pRT commented Jan 10, 2017

From @Leont

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

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

On Tue, Jan 10, 2017 at 12​:26 PM, Sawyer X <xsawyerx@​gmail.com> wrote​:

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

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

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

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

Leon

@p5pRT
Copy link
Author

p5pRT commented Jan 10, 2017

From @khwilliamson

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

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

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

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

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

Leon

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

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

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2017

From @xsawyerx

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2017

From @khwilliamson

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2017

From @khwilliamson

On 04/06/2017 01​:05 PM, Karl Williamson wrote​:

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"

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2017

From @khwilliamson

Reopened
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2017

From @khwilliamson

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2017

From @khwilliamson

On 04/06/2017 03​:51 PM, Karl Williamson wrote​:

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 7, 2017

From @cpansprout

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.

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

@p5pRT
Copy link
Author

p5pRT commented Apr 7, 2017

From @xsawyerx

On 04/07/2017 02​:46 AM, Father Chrysostomos via RT wrote​:

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 7, 2017

From @kentfredric

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

--
Kent

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

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2017

From @khwilliamson

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

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2017

From @xsawyerx

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?

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

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From @khwilliamson

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.

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

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.

[1] This is a real word, I checked.

Don't misunderestimate.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From @iabyn

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From @khwilliamson

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From @khwilliamson

0004-minimal-lbrace-patch.patch
From f676c52876b6e6ccb34c9410a6557343356d9877 Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Mon, 10 Apr 2017 11:12:53 -0600
Subject: [PATCH 4/4] minimal lbrace patch

---
 regcomp.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/regcomp.c b/regcomp.c
index 810c457..27a77f3 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -13387,8 +13387,13 @@ S_regatom(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth)
 		     * literal string, or when it's the first thing after
 		     * something like "\b" */
 		    if (len || (p > RExC_start && isALPHA_A(*(p -1)))) {
+                        if (memNEs(RExC_start, RExC_end - RExC_start, "\\${[^\\}]*}")) {
                         RExC_parse = p + 1;
 			vFAIL("Unescaped left brace in regex is illegal here");
+                        }
+                        if (PASS2) {
+                            ckWARNregdep(p + 1, "Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through");
+                        }
 		    }
 		    goto normal_default;
                 case '}':
-- 
2.7.4

@p5pRT
Copy link
Author

p5pRT commented Apr 12, 2017

From @xsawyerx

On 04/10/2017 06​:20 AM, Karl Williamson wrote​:

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

(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? :)

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.

[1] This is a real word, I checked.

Don't misunderestimate.

<3

@p5pRT
Copy link
Author

p5pRT commented Apr 12, 2017

From @jkeenan

On Wed, 12 Apr 2017 09​:06​:08 GMT, xsawyerx@​gmail.com wrote​:

On 04/10/2017 06​:20 AM, Karl Williamson wrote​:

On 04/09/2017 12​:01 PM, Sawyer X wrote​:

[snip]

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)

@p5pRT
Copy link
Author

p5pRT commented Apr 16, 2017

From @iabyn

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?

--
Overhead, without any fuss, the stars were going out.
  -- Arthur C Clarke

@p5pRT
Copy link
Author

p5pRT commented Apr 16, 2017

From @cpansprout

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.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2017

From @khwilliamson

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2017

From @Leont

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.

Leon

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2017

From @jkeenan

On 04/17/2017 10​:18 AM, Leon Timmermans wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2017

From @xsawyerx

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!

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2017

From @haarg

On Mon, Apr 17, 2017 at 4​:18 PM, Leon Timmermans <fawaka@​gmail.com> wrote​:

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​:
golang/go#20007

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2017

From @khwilliamson

On 4/17/2017 11​:04 AM, Sawyer X wrote​:

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 7335cb8

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2017

From @khwilliamson

On 4/17/2017 8​:18 AM, Leon Timmermans wrote​:

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant