-
Notifications
You must be signed in to change notification settings - Fork 531
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
Remove cachemgr.cgi tool #1542
Remove cachemgr.cgi tool #1542
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
big cleanup!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for removing this tool!
If this change should be reflected in doc/release-notes/release-7.sgml.in, please adjust accordingly. FWIW, recent commit 80cba6d did adjust those release notes when removing squidclient.
If possible, please adjust the following three leftovers as well:
INSTALL:27:the tools/cachemgr.cgi program into your httpd server's cgi-bin
src/cf.data.pre:7533: SNMP responses, cachemgr.cgi output, squidclient User-Agent request header
tools/purge/purge.1:288:.if !'po4a'hide' .BR cachemgr.cgi "(8)"
Done in 64f2af0
Done in 90bc05c
This one is left intentionally to avoid conflicts with PR #1541 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not insist on any changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ship it!
0d1d8f6
to
a0980f8
Compare
Co-authored-by: Alex Rousskov <[email protected]>
Co-authored-by: Alex Rousskov <[email protected]>
a0980f8
to
f304e48
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure what exactly went wrong because forced push erased breadcrumbs, but it looks like that recent force-push broke this PR. FWIW, please keep in mind that forced pushes to PR branches are very rarely necessary and, in most other cases, create more problems than they solve.
Yes, it would have invalidated the approvals, but, in this particular case, those invalidations would not cause any additional delays because this PR is authored by Amos (so his implicit approval does not get invalidated by changes), the changes would be committed by you (so you would, presumably, immediately re-approve), and the PR is more than two days old (so my/third approval would not speed things up). If it were your PR, I would have committed these trivial changes myself (instead of posting change requests) under to our "Easier Done" agreement, but I do not have a similar permission from Amos. FWIW, this invalidation is a GitHub configuration option. We can turn it off, but I think it is the necessary evil, especially for PRs coming from folks that are not intimate with git (and may accidentally push unwanted changes that may get merged automatically). There are other solutions to mitigate that risk, but, AFAICT, they all require development and they all make the process more complex by adding more exceptions or special rules. |
Had to rebase manually due to conflicts. |
Resolving merge conflicts does not require rebasing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving without a careful review under the assumption that there were no material charges since the last review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Expediting along. I’m confident any issues would have been caught by CI
No description provided.