Source Format Enforcement

[squidadm]

Reference point for automated CONTRIBUTORS updates

[rousskov]

I do not know whether this PR was created by automation or a human, but it makes nearly 2000 files different from their master/v8 and v6 equivalents. These changes do not actually affect the copyright status of Squid code. Do v7 maintainers feel these ~2000 changes are really necessary?

If this PR was an automation accident, please adjust your script to mimic the corresponding source maintenance job in CI.

[yadij]

I do not know whether this PR was created by automation or a human, but it makes nearly 2000 files different from their master/v8 and v6 equivalents. [...]

If this PR was an automation accident, please adjust your script to mimic the corresponding source maintenance job in CI.

This PR is the automated creation of the CI script. I have just yesterday managed to find time to look into why there has been a slow accumulation of small formatting issues come up. See squid-cache/ci#33 for details on that.

These changes do not actually affect the copyright status of Squid code.

That is a false statement.

FTR; There exist countries with copyright laws where the stated time period determines when the copyright lapses into Public Domain. That can be a surprisingly short time. The changes made here to copyright statements actively extend that period by +2 years before our code lapses into Public Domain "historic" permissions.

Do v7 maintainers feel these ~2000 changes are really necessary?

Yes.

[rousskov]

These changes do not actually affect the copyright status of Squid code.

That is a false statement.

I obviously disagree with that opinion.

There exist countries with copyright laws where the stated time period determines when the copyright lapses into Public Domain. That can be a surprisingly short time. The changes made here to copyright statements actively extend that period by +2 years before our code lapses into Public Domain "historic" permissions.

My statement does not contradict the above "extend by 2 years" assertion. I also seriously doubt the validity of that assertion itself. Actual copyright expiration is unlikely to be affected by such trivial edits.

Do v7 maintainers feel these ~2000 changes are really necessary?

Yes.

IMO, they should be applied to master/v8 first then (which I will object to).

[kinkie]

This is a deja vu discussion.
Yes, updating boilerplat is a hassle. But time and time again the outcome of that discussion has been to do it.
What is it this time that is different past iterations of this discussion?

[rousskov]

What is it this time that is different past iterations of this discussion?

A few things have changed, including:

• Previous iteration was a PR against the master branch. This PR is against a release branch (while master has not changed).
• We have enjoyed one "extra" year of no boilerplate changes without known major negative consequences.
• Repeated sacrifices and investments on my part have not resulted in an increased cooperation; the level of cooperation actually went down.

It was also possible (at the time of my review of this PR) that the previously missing information/arguments in support of changing ~2000 files have been discovered. AFAICT from the responses, that is not the case (but I could not have known that at the time).

[yadij]

What is it this time that is different past iterations of this discussion?

A few things have changed, including:

* Previous [iteration](https://github.com/squid-cache/squid/pull/763#pullrequestreview-579383507) was a PR against the master branch. This PR is against a release branch (while master has not changed).

The only relevance to that being @rousskov repeated claims to the effect, if not actual wording, of "[He] dont know anything about maintenance" and "have no interest in performing maintenance", and "will not make maintenance decisions about release branches".

Yet here we are, arguing with him about a maintainer decision concerning what gets published in the release branch.

* We have enjoyed one "extra" year of no boilerplate changes without known major negative consequences.

No on both claims.

• "major negative consequences":

  • All contributions to Squid within the 2024-2025 years are right now on legally contentious status regarding whether they are GPL protected or currently in Public Domain copyright.
  • Authors contributed expecting their code to be GPL protected, as claimed by The Squid Software Foundation license blurb.

• "We have enjoyed":

  • Here in NZ, as the author I received 8 years instead of 10 years for protection. As a company my sponsor lost all rights of protection, instead of sharing those short 10 years.
  • This is absolutely not something to "enjoy". Unless one is seeking to steal said copyright works for GPL violating purposes. I truly hope you are not being that bad.

* Repeated sacrifices and investments on my part have not resulted in an increased cooperation; the level of cooperation actually went down.

Cooperation as defined by the things accepted and the things argued has not changed. AFAICS, Your demands have increased over time. Thereby earning an increasing amount of pushback against the rejected demands.

• 2013-2019:
  • no comments or just "OK to test", indicating you at least saw the changes.
• 2020:
  • non-blocking comment "Someday we should remove this ..."
• 2021:
  • non-blocking comment "I suggest removing the years from copyright statements"
• 2022:
  • 4 days arguments with maintainers daring to perform maintenance duties without @rousskov personal approval.
  • non-blocking request on master branch "I think we should not update copyright years every year,"
• 2023:
  • master branch; non-blocking request "we should not update copyright years"
  • release branch; non-blocking objection to maintainer decisions "I am against merging this PR"
• 2024:
  • bug prevents maintenance script operation.
• 2025:
  • blocking veto's on PRs for developer branch master, release branch v7 and old stable branch v6.

FYI; from what I can see in the 2021 PRs github record you appear to be using "git cherry-pick" to update each your patch branches individually from master branch. That is not a good way to maintain them with git, and likely the source of your pains regarding these particular updates. Using rebase or merge/pull on the relevant base branch or HEAD/commit there is far less trouble from accidentally skipped chunks.