-
Notifications
You must be signed in to change notification settings - Fork 640
Source Format Enforcement #2041
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,5 @@ | ||
| /* | ||
| * Copyright (C) 1996-2023 The Squid Software Foundation and contributors | ||
| * Copyright (C) 1996-2025 The Squid Software Foundation and contributors | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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.
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.
Yes.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I obviously disagree with that opinion.
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.
IMO, they should be applied to master/v8 first then (which I will object to).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a deja vu discussion.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
A few things have changed, including:
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).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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.
No on both claims.
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.
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. |
||
| * | ||
| * Squid software is distributed under GPLv2+ license and includes | ||
| * contributions from numerous individuals and organizations. | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.