-
Notifications
You must be signed in to change notification settings - Fork 18
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
Apply the double-search change to simple search #208
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
So hold on, in https://github.com/LibriVox/librivox-catalog/pull/207/files#diff-cb39737e00dff1ebcb3d8fc914228975e384415679c2f9495c369c537b65318cR183 you changed the code to use the
full_count
directly in the search results. In that same PR, you modifiedadvanced_title_search()
to return the full count, but you didn't touchsimple_search()
. You're makingsimple_search()
return thefull_count
in this PR, so my question is - how does simple search even work currently now? It seems to work, but I'm not sure I understand how.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.
Since that first PR was merged, simple search does not work on current master. It wants that column, but doesn't get it.
Since it is working in prod right now, it must still be running a version before that PR.
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
git pulled
in prod when I merged that PR. Very curious...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 just tested again: current master still fails on simplesearch, giving an HTML error message rather than the JSON array the page expects.
I don't know how that
git pull
could have failed, but I'm glad it didn't take, until this one is in. We did say simplesearch needed patched. 😬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.
Can you link an example? I'm legit trying every search that I know of, and they all appear to be working.
You did, and I think this is a case of my day job expectations and assumptions leaking into LibriVox. In my day job, master is always working, and we never knowingly merge broken or incomplete code. In my mind this is a shared understanding that everyone else, including yourself, has as well, in all projects. That's obviously not the case.
I would strongly prefer if we made such a policy explicit for LibriVox: never knowingly merge broken or incomplete code, even if we don't have the CI coverage needed to automatically enforce that. But this is something that we can discuss.
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.
Edit: In case you saw the earlier version, this has been edited. For some reason, it's not showing the 'Edited' tag.
That would seem to be because master isn't what's in prod. With my dev instance on librivox/master, I get nothing but a spinning wheel.
I share the same expectation: nothing that isn't working should actually make it in to master. I just didn't think I was merging the incomplete code. I think I see the disconnect.
The PR was tagged with "[Sanity Check]", which you recognized as meaning that it needed some feedback. I should have also been more explicit (as Gareth was in his comment) that it was not complete even if it was the right technical direction.
When you asked if I had "any objections to merging this", I thought you referred to the PR in general, which I thought we all knew was not complete and needed a second commit. So I said:
Perhaps I should have instead said:
We can also talk through email if you prefer.
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.
Prod is definitely on latest master, hence my asking for an example or URL where I can hopefully see simple search failing, if only on staging or localdev.
I'm used to the "[WIP]" (Work in Progress) or "[DNM]" (Do Not Merge) tags in the commit message title. DNM is much stronger and indicates trying to debug something, often with the CI system itself. The expected outcome of a DNM patch is for it to be abandoned. WIP indicates that the patch isn't ready to merge yet, but there's an expectation that the WIP tag will get removed, at which point the patch will be ready to merge. In retrospect, PR #207 should have been a [WIP].
In my day job, because we use Gerrit and a gating CI, there's also the handy vote system, so the patch author can vote "Workflow -1" on their own patch, clearly indicating that they don't want it to merge at this time. We can try something similar here, by requiring approval from yourself (@redrun45) and myself on all patches (and potentially @garethsime if they're willing to accept the responsibility?). That way, if you're proposing a PR that isn't ready yet, you can disapprove your own PR, and then change your approval once it's ready.