Implement "patchr" as a d.o user enhancement

I haven't personally used Review Board, but my partner Zach used it at his last company. He has nothing but good things to say about it... some specific points he mentioned:
- It integrates with Git (as well as other VCS; they used both Git and Perforce at Zach's company).
- It supports multiple versions of patches and allows you to look at differences between any two patches and/or the source code.
- You can comment on specific lines of the patch, and people can respond to the comments on those lines of the patch. MUCH better than dreditor in that regard.
- It is open source and has an active, responsive developer community (MIT license).
- It is written in Python / MySQL (also runs on PostgreSQL and SQLite).
- At Zach's company, they had it integrated with their user accounts so it didn't require a separate login... but that was on a company network.
- There is a command-line utility that supports sending something to review to it.

I looked through the documentation a bit... It is basically a stand-alone web application, with its own database and authentication system (user accounts etc.). However, it does support LDAP and Active Directory
https://www.reviewboard.org/docs/manual/2.5/admin/configuration/authenti...
so maybe we could get it to authenticate through drupal.org? Unsure, not my area of expertise.

Connecting it with our existing project/issue/patch system could be a pain... but maybe not? It does have a REST API:
https://www.reviewboard.org/docs/manual/2.5/webapi/

Anyway... I think this would be a much better option than trying to add dreditor's patch review to drupal.org. It has a lot of features, and is maintained elsewhere.

> - You can comment on specific lines of the patch, and people can respond to the comments on those lines of the patch. MUCH better than dreditor in that regard.

That's my concern with it -- it's a whole threading system of its own, and I don't yet see how that would integrate with the comments on an issue.

Yes, it would definitely be a different workflow. We could move into the 21st century.

What I mean is that the discussion about a particular issue would get fragmented between the issue node and multiple patch comment threads.

That is true. We would have to get into the habit of discussing the code on Review Board, and other stuff in issue comments.

But in my opinion, this would be a huge improvement. Discussing the code changes in issue comments is cumbersome to do, and difficult to follow. You cannot easily see what change is being discussed in each comment, compare the lines being changed to the context of the rest of the code, etc. Review Board is made for discussing changes to code, and is a mature solution for doing that. I think the fragmentation that would result is worth it.

It would, but it's still fragmentation.

As much as using standard tools is a good aim to pursue, I'm not sure we have the resources to work on integrating this in the short time required.

I think a simpler stop-gap would be to extract the JS that powers Dreditor's patch review process and add it to d.org's site JS.

I think we may have some discussions of a review tool for d.o.
Made a spot in the summary for background
and added one.

Fine with me! Agreed with earlier discussions that implementing something like Github's review features or Review Board is a much more compicated task and will require more developer buy-in.

It looks like all the patch review functionality is in src/js/plugins/patch.review.js.

I had a go at running that in Greasemonkey and got... nothing. But I am in no way a JS coder, so I've no idea where to go from there.

This should be the dedicated issue for implementing what I previewed in #1673278-29: [PP-1] Add user_enhancements to d.o for smaller Dreditor features:

https://github.com/unicorn-fail/dreditor
https://github.com/unicorn-fail/dreditor-ui

That issue is now, primarily, about focusing on porting the rest of the other features of Dreditor.

I suppose it's also dependent on that issue being committed.

In an effort to avoid confusion with the previous "Dreditor" browser extensions and the new patch review code that was developed, that new code has been split into a new separate project named "patchr":

https://github.com/unicorn-fail/patchr
https://github.com/unicorn-fail/patchr-ui

In the next few weeks, we hope to enable merge requests for all Drupal.org projects, #2205815: Merge requests in Drupal.org issue queues?. Maintainers may still accept patches for some time, there will be some transition period when DrupalCI testing for both patches and merge requests is enabled. When merge requests are in a solid place, we could even automate opening merge requests for all patches that still apply. In the meantime, we’ll be concentrating on making merge requests work well, and I don’t think it is a good time to add any more infrastructure around patches that will be short-lived.

That doesn't retroactively affect existing patches in existing issues. Viewing issues from years ago may still include viewing patches; this could still be greatly beneficial.