Replace cherrypy.lib.lockfile with zc.lockfile. #1729
Conversation
@@ -564,8 +571,9 @@ def acquire_lock(self, path=None): | |||
|
|||
def release_lock(self, path=None): |
webknjaz
Aug 15, 2018
Member
Having a path arg here looks weird to me: it's not used anywhere.
Having a path arg here looks weird to me: it's not used anywhere.
v17.3.0 | ||
------- | ||
|
||
* :issue:`1193`: Rely on zc.lockfile for session concurrency |
webknjaz
Aug 15, 2018
Member
via :pr:`1729`
it helps a lot when I'm trying to verify things
via :pr:`1729`
it helps a lot when I'm trying to verify things
jaraco
Aug 16, 2018
Author
Member
I'll do it this time, but I'm really disinclined to do this extra work in general and here's why: Usually, the user wishes to know the "why" of a change (the issue) and is less interested in the "how", so the issue number is usually more relevant. Moreover, the PR number is often not known at the time the PR is submitted, so requires a two phase process - commit changes, create PR, commit more changes. I want to avoid adding extra steps. As long as the changelog gives a link to a relevant issue (preferably the most relevant issue), it's a small matter from there to see the other activity that's linked, including PRs. I don't want to recommend or ascent to manual processes that replicate information that's readily available through automatic processes. I will sometimes link to a PR when there's no issue present or if that PR is somehow not readily reachable from the issue, but my preference is to link to one issue and let an investigator trace that to the PR with one extra click.
I'll do it this time, but I'm really disinclined to do this extra work in general and here's why: Usually, the user wishes to know the "why" of a change (the issue) and is less interested in the "how", so the issue number is usually more relevant. Moreover, the PR number is often not known at the time the PR is submitted, so requires a two phase process - commit changes, create PR, commit more changes. I want to avoid adding extra steps. As long as the changelog gives a link to a relevant issue (preferably the most relevant issue), it's a small matter from there to see the other activity that's linked, including PRs. I don't want to recommend or ascent to manual processes that replicate information that's readily available through automatic processes. I will sometimes link to a PR when there's no issue present or if that PR is somehow not readily reachable from the issue, but my preference is to link to one issue and let an investigator trace that to the PR with one extra click.
Codecov Report
@@ Coverage Diff @@
## master #1729 +/- ##
=========================================
- Coverage 80.89% 80.8% -0.09%
=========================================
Files 105 104 -1
Lines 13597 13525 -72
=========================================
- Hits 10999 10929 -70
+ Misses 2598 2596 -2 |
550a17a
into
master
I hope this change addresses #1193. Presumably supersedes #1705.