Page MenuHomeFreeBSD

www/foswiki: Remove redundant escape
ClosedPublic

Authored by kevans on Feb 15 2020, 5:33 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 1 2024, 5:45 PM
Unknown Object (File)
Feb 1 2024, 5:41 PM
Unknown Object (File)
Feb 1 2024, 5:40 PM
Unknown Object (File)
Jan 30 2024, 12:10 PM
Unknown Object (File)
Jan 30 2024, 7:47 AM
Unknown Object (File)
Jan 9 2024, 9:11 AM
Unknown Object (File)
Dec 20 2023, 7:33 AM
Unknown Object (File)
Dec 12 2023, 1:29 AM
Subscribers

Details

Summary
www/foswiki: remove redundant escape

= does not need to be escaped in this context; bug #229925 aims to make
escape of most ordinary characters an error to reduce friction when some
of these ordinary characters are later granted special GNU-extended
behavior.

No functional change, no need to bump PORTREVISION.

PR: 240309
Approved by: koobs (mentor), portmgr (maintainer timeout: 4 months)
Differential_Revision: D23698
Test Plan

Q/A:

  • testport (12.0 amd64, -HEAD w/ 229925 applied)

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Feb 15 2020, 5:39 PM
koobs retitled this revision from www/foswiki: remove redundant escape to www/foswiki: Remove redundant escape.Feb 17 2020, 1:33 AM
koobs edited the summary of this revision. (Show Details)

For ports that have maintainers that have Phabricator accounts, its nice to add them to Reviewers: even if an existing PR exists and even in the case of an implicit/blanket/other approval, as a heads up

Anything that isn't a version update (unless its a security, bug fix release version update), is a MFH candidate. More precisely, there ought to be a reason (by policy or otherwise) not to MFH something, and in particular, merging things makes future merges easier (as one has to either commit all intervening commits anyway, or do direct to quarterly merges, which can be risky

Is there a present or future (upcoming base change for example) impact of not removing the redundant escape? If so, clarify that in commit message

make escape of most ordinary characters an error appears to get at the impact, but it wasn't entirely clear, at least to me, whether its theoretical, or whether leaving the escape in place would return an error if not removed, after the relevant base change was commited

Is there a present or future (upcoming base change for example) impact of not removing the redundant escape? If so, clarify that in commit message

make escape of most ordinary characters an error appears to get at the impact, but it wasn't entirely clear, at least to me, whether its theoretical, or whether leaving the escape in place would return an error if not removed, after the relevant base change was commited

Indeed- the implied part of these changes is that they're being made specifically because they are erroneous. I could make others on the basis of correctness, but have opted not to do so for now.

If its possible to make the commit log message more obvious that not fixing this ''will'' be an error after 229925, then do so, but not a dealbreaker

I'm with @koobs on an "informative" error returned on this. If it's possible.
I think it might lend itself to *Maintainers* providing a cure. :)
Thanks for all the time, and effort put into this!

This revision was automatically updated to reflect the committed changes.