Revert inappropriate PSR-12 post-vote merge

67 views
Skip to first unread message

Larry Garfield

unread,
Sep 18, 2019, 12:42:47 PM9/18/19
to PHP-FIG
Hi all.

I noticed this morning that this PRs had been merged against PSR-12:

https://github.com/php-fig/fig-standards/pull/1185
https://github.com/php-fig/fig-standards/pull/1183

I do not believe the changes in them are appropriate for an already-voted-on PSR. Changes post-vote are permitted in only very narrow circumstances:

https://www.php-fig.org/bylaws/psr-amendments/#3-acceptable-amendments

The following changes in that PR go well beyond Annotations or Formatting & Typos:

https://github.com/php-fig/fig-standards/pull/1185/files

Changing "would not" (a non-binding term) to a "MUST NOT" (an RFC defined term with very specific meaning) is a substantive change. The original "Would not" language is, in context, entirely adequate.

https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L99

This block changes the meaning of the spec, and thus is not allowed.

https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L369

Because capitalized MUST has a specific "legal" meaning, this is also technically a substantive change.

https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L439

Substantive change, and isn't even explained.

https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L464

While this is a net-zero impact change because the language already requires it, I would still say it's more than is allowed without an errata.

https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L689

These buts don't really add anything. (Insert inappropriate joke here.)

https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L885

This change is even noted in the comments as being a substantive change. This is not acceptable post-vote.

https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9R918

I... don't even know what this is about at all.

As a result, what is currently published as PSR-12 is not what was approved by the Core Committee. That situation must be corrected.

I ask the Secretaries to revert both PRs promptly. Additionally, I do not believe PRs to approved specs should be merged by anyone other than the Secretaries, as they are the ones nominally responsible for typo-fix level changes.

There are some non-substantive changes in the larger one that are fine (adding newlines and fixing some commas or capitalization), which can be resubmitted. Any substantive changes must go through an Errata vote, and if approved added to the meta document.

(Note: I am not making any statement here on the substance of those changes, and whether they're good or bad for the spec. Just that they are inappropriate at this time.)

--
Larry Garfield
la...@garfieldtech.com

Korvin Szanto

unread,
Sep 18, 2019, 1:21:40 PM9/18/19
to php...@googlegroups.com
Hi Everyone,
I totally agree that merging #1183 was an overstep on my part, the bylaws are clear that it should be a secretary managing merging and not the editor of the PSR. I also agree that some of these changes would qualify for errata, I appreciate you paying attention and holding me accountable.

That said I think our bylaws are a little too open when it comes to managing these sorts of changes. Once a PSR is accepted, secretaries are charged with managing "typos, changes or errata" with the optional help of the editor: 
> If the Acceptance Vote passes, ... the Working Group is automatically dissolved, however the Editor’s input (or a nominated individual communicated to the secretaries) may be called upon in the future should typos, changes or Errata on the specification be raised.

The "typos" and "changes" portion of that is classified more specifically in the Amendments bylaw as "formatting and typo" fixes:

> If formatting is broken for any reason then changing formatting must not be considered a change to the document. These can be merged or pushed without hesitation by a secretary, as long as they don’t change anything of any meaning or syntax.

So secretaries are expected to ensure modifications are "not ... considered a change to the document" and "don’t change anything of any meaning or syntax" with the occasional help of the Editor as needed. In practice, as demonstrated here these things are subjective and can be interpreted differently by different individuals. In this case, both the Editor of the PSR and current secretaries looked at these changes and agreed they could be merged without errata votes.

I think we should consider changing the typos and formatting change process so that it's less subjective and more likely to result in stable specifications. Perhaps we could have a subcommittee in the CC that has to give blessing to merge changes to any approved specification.

Thanks again for keeping an eye on these things Larry,
Korvin

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/48c58f56-2f61-4d02-9b04-ef7f71fd3de4%40www.fastmail.com.

Alessandro Lai

unread,
Sep 19, 2019, 5:02:02 PM9/19/19
to PHP Framework Interoperability Group
Since the PRs are opened by the editor and are approved by all 3 secretaries, I'll proceed to merge them.

Korvin, it's up to you to reopen the discussion that will lead to the errata vote then.

Sorry for the mixup.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages