Front page | perl.perl5.porters |
Postings from February 2017
[perl #130497] Revert "Unescaped left brace in regex" fatality
Thread Previous
From:
James E Keenan via RT
Date:
February 6, 2017 16:23
Subject:
[perl #130497] Revert "Unescaped left brace in regex" fatality
Message ID:
rt-4.0.24-27713-1486398205-297.130497-15-0@perl.org
On Fri, 20 Jan 2017 00:36:59 GMT, public@khwilliamson.com wrote:
> On 01/17/2017 02:52 PM, Leon Timmermans wrote:
> > On Tue, Jan 17, 2017 at 9:10 PM, Sawyer X <xsawyerx@gmail.com
> > <mailto:xsawyerx@gmail.com>> wrote:
> >
> > On 01/16/2017 07:28 PM, Leon Timmermans wrote:
> > > On Sat, Jan 14, 2017 at 9:38 PM, Sawyer X <xsawyerx@gmail.com
> > > <mailto:xsawyerx@gmail.com>
> > > <mailto:xsawyerx@gmail.com <mailto:xsawyerx@gmail.com>>> wrote:
> > >
> > > Going back to the original discussion on the value of making
> > > this
> > > change
> > > this way vs. reverting and then doing it again: there is a
> > > considerable
> > > value in doing it now. Introducing iterative changes is easier
> > > (for
> > > users) than introducing one major breakage that includes many
> > > different
> > > changes.
> > >
> > >
> > > Can you concretize this for me? Preferably something like
> > > "doing this
> > > now enables us to do X in the next release, which would
> > > otherwise not
> > > be possible".
> >
> > I'm not sure this is the best way to phrase what I meant, but let me
> > try
> > using these terms:
> >
> > The regular expression syntax has been cleaning up over time. This
> > allowed us to remove possible problems, clean up confusing syntax,
> > tighten up the syntax, and even add features (/xx was just reused a
> > few
> > commits ago by khw). This specifically is a good example, because it
> > shows khw's long-term plans, which he works out in piecemeal, making
> > small changes each time, eventually create enough room to introduce
> > something new.
> >
> > If we had done all the changes that would facilitate these new
> > features
> > or fixes in one pass, it would have broken a wider range of modules
> > and
> > programs in numerous ways. This would have taken longer to figure
> > out,
> > to provide pull requests and patches for, to convince authors to
> > merge
> > and release new versions, and could eventually lead to more
> > frustration
> > with authors who have written code that now broke in multiple ways.
> >
> > My point is that while this breakage *will* occur, there is an value
> > in
> > making only *this* one this time, instead of this *plus* another in
> > the
> > next version. That's not to say I'm strongly opposed to reverting
> > this.
> > Neither is Karl.
> >
> >
> > I think you missed my point, you're giving a philosophical answer
> > where
> > I'm asking for a tangible result.
> >
> > > Given the other left-braces warning I don't see how there is
> > > any X for
> > > the next two releases, making this hurry pointless to me.
> >
> > I'm sorry. I didn't understand this sentence.
> >
> >
> > As far as I know, Karl (correct me if I'm wrong) can't execute his
> > long-term braces plan (a tangible result) until the other warning
> > becomes fatal too (after 5.30).
> > Not fatalizing this warning now will not obstruct any future plans as
> > far as I can tell, and will allow for a smoother upgrade path to 5.26
> > (giving people more time to escape their braces).
> >
> > Leon
>
>
> I'd have to spend some time figuring out what could be done with the
> portion of the braces gone in 5.28. As I recall, it wouldn't be a
> lot.
> That's why I haven't been too concerned about reverting.
>
> But since this is viewed as a bug fix, it doesn't have to be done in
> time for the visible changes load, so we have more time to discuss it.
Until Jan 31 CPANtesters was impeded from getting a full picture of the impact of this fatalization on the building and testing of CPAN distributions because one distribution with over 600 first-level reverse dependencies was failing for this reason in one test, preventing the full testing of that distribution and all distributions which depended upon it.
That situation has now been remedied. (Kudos to Toby, Nigel, sawyer and many others for their attention to this situation.) CPANtesters is therefore now in a much better position to assess the impact of this fatalization on CPAN as we head to 5.26.0.
Over the last week I used 'cpanm' to build and test that distribution (Type-Tiny) and all its reverse dependencies. I am pleased to report that I discovered only one previously unreported instance of a CPAN distribution getting a FAIL due to this fatalization. I filed a bug report for that ticket. Slaven, Andreas, Karen E and others have already filed bug reports for all other CPAN distributions experiencing FAILs due to this fatalization. (Details available upon request.)
Therefore IMO there is no significant barrier to the implementation of this fatalization in 5.26.0. I would not be in favor of delaying this implementation until 5.28, though I acknowledge other people think otherwise. But we have IMO taken every step we practically can to warn users of potential problems.
Hence, I recommend that we *not* perform the reversion cited in the subject of this ticket.
Thank you very much.
Jim Keenan
--
James E Keenan (jkeenan@cpan.org)
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=130497
Thread Previous