Remove forbidden @author tag from framework (part 1)

[fredden]

Description

According to https://devdocs.magento.com/guides/v2.4/coding-standards/docblock-standard-general.html#documentation-space, the @author tag is not permitted in Magento. This pull request removes this tag from some modules. Given there are so many instances of this tag, I've opened a small pull request to get the process started. I expect that the linter will force me to fix several other coding standards violations on the way, so having a smaller pull request means that task is easier to manage. I plan to open more pull requests to tackle the other instances of this tag.

See also magento/magento-coding-standard#382 and magento/magento-coding-standard#167

Manual testing scenarios

There are not code changes in this pull request. This pull request only removes forbidden comments.

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

Resolved issues:

1. resolves [Issue] Remove forbidden @author tag from framework (part 1) #37268: Remove forbidden @author tag from framework (part 1)

[m2-assistant]

Hi @fredden. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.

Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[leonhelmus]

Looks good to me!

[leonhelmus]

@magento create issue

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[ihor-sviziev]

Adding the same priority as #36976 (comment)

[engcom-Lima]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.

[engcom-Lima]

✔️ QA Passed

Preconditions:

• Install fresh Magento 2.4-develop and PHP 8.1

Manual testing scenario:

• Verified @author tag got removed from framework.

Before: ✖️

After: ✔️

No additional manual test cases is required as part of regression as this PR is related to the removal of @author tag from framework module.
Builds are failed. Hence, moving this PR to Extended Testing.

[engcom-Echo]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.

[engcom-Charlie]

@magento run Semantic Version Checker

[engcom-Charlie]

@magento run all tests

[engcom-Charlie]

@magento run all tests

[engcom-Charlie]

@magento run all tests

[engcom-Charlie]

@magento run all tests

[engcom-Charlie]

/ pass, but the result has come back as a failure. I'll update this branch and run the tests again. If the error persists, I recommend you get this investigated internally as there seems t

Hi @fredden,

Thank you for your contribution!

This is the error what we are getting and which is causing the SVC failure.

[engcom-Charlie]

Hi @fredden,

Can you please have a look into above issue. We are getting this error in build result.

Thank you!

[engcom-Charlie]

@magento run all tests

[engcom-Charlie]

Hi @fredden,

Thank you for your contribution!

Can you please have a look into above mentioned SVC error.

Thank you!

[fredden]

@engcom-Charlie the updated comment is correct / more helpful. The function never throws a LocalizedException, but does sometimes throw a NotEnoughFreeSpace exception.

magento2/lib/internal/Magento/Framework/Backup/Filesystem.php

Lines 164 to 179 in 5ebdfb5

	* @throws LocalizedException
	*/
	public function validateAvailableDiscSpace($backupDir, $size)
	{
	$freeSpace = disk_free_space($backupDir);
	$requiredSpace = 2 * $size;
	if ($requiredSpace > $freeSpace) {
	throw new NotEnoughFreeSpace(
	new Phrase(
	'Warning: necessary space for backup is ' . (ceil($requiredSpace) / 1024)
	. 'MB, but your free disc space is ' . (ceil($freeSpace) / 1024) . 'MB.'
	)
	);
	}
	}

[engcom-Charlie]

@magento run all tests

[orlangur]

Hi @fredden @leonhelmus @ihor-sviziev !

Why do we have

changes introduced in such an awkward way at all?

It is much easier to fix it all over the codebase at once, enforce with coding standard rule and provide an automated way for somebody processing it from Adobe side to do the same for closed-sourced repositories. Such approach worked perfectly in #8685 to fix ALL PSR-2 violations, not just such a simple thing like one tag.

[fredden]

@orlangur due to the way the testing suite is configured, any modified files must pass all current coding standards, but files not modified are excluded from many static analysis checks. This means that as the coding standard evolves, the codebase is slowly brought up to compliance, but also that changes in the coding standard are not enforced on the whole codebase.

This change could easily be made by running phpcbf as a one-off action. I have previously offered to introduce such a process and this has been declined by Adobe.

I split this particular change (see magento/magento-coding-standard#382 and magento/magento-coding-standard#433) into several parts because I knew that by modifying these files would mean that other coding standards would then be applicable and enforced. Putting all such changes into a single pull request would have meant that no progress would be made due to the review burden involved. With several small pull requests, each pull request requires minimal review and can be merged in trivially. I did expect that all of these pull requests would be merged in within a short period of time, but that is not the case.

[leonhelmus]

@orlangur similar to @fredden i agree with the reaction of @fredden. Also i tried to introduce a fix for the test suite but it never got traction. magento/magento-semver#70

[orlangur]

any modified files must pass all current coding standards, but files not modified are excluded from many static analysis checks. This means that as the coding standard evolves, the codebase is slowly brought up to compliance, but also that changes in the coding standard are not enforced on the whole codebase.

Full codebase coding standard compliance is exactly what I achieved in #8685 and it was broken later for no reason.

My expectation is that we should not spend manual review efforts on changes which could be done in an automated way, another good example is "constructor property promotions". So, it's enough to review automation steps and then apply them without need to review the changes with bare eye.

Thanks for the information and more context @fredden and @leonhelmus, I'll try to elaborate an effective process which Adobe can accept.

[engcom-Charlie]

@magento run all tests

[engcom-Charlie]

@magento run all tests

[engcom-Charlie]

Hi @fredden,

Did you get a chance to fix the SVC failure mentioned here.

Thank you!

[fredden]

Hi @fredden,

Did you get a chance to fix the SVC failure mentioned here.

Thank you!

I have already replied to this query. See #37018 (comment)

[engcom-Charlie]

@magento run all tests