search for: reviewers

If anybody on edge familiar with this could help, that would be "great" :) I have different types of things I want to be "reviewable". So, instead of having a slew of HABTM... this new Polymorphic Associations schtick seemed like the best solution. I have everything setup as I thought it should be (so I think)... but it doesn''t appear to be working correctly. Here

...hile to try and match open Phabricator reviews to people who might be able to review them well. I received quite a few requests to share that script, so I've decided to do so, see https://reviews.llvm.org/D46192. The script uses 2 similar heuristics to try and match open reviews with potential reviewers: - If there is overlap between the lines of code touched by the patch-under-review and lines of code that a person has written, that person may be a good reviewer. - If there is overlap between the files touched by the patch-under-review and the source files that a person has made changes to...

...ments and/or test cases can often help (and asking for comments in the test cases is fine as well).  2. If you review a patch, but don't intend for the review process to block on your approval, please state that explicitly. Out of courtesy, we generally wait on committing a patch until all reviewers are satisfied, and if you don't intend to look at the patch again in a timely fashion, please communicate that fact in the review.  3. All comments by reviewers should be addressed by the patch author. It is generally expected that suggested changes will be incorporated into the next revi...

With the help of several heroes here yesterday I beat my way into a working solution to adding comments to one or more models in my application using acts_as_comentable. Great plugin, but my implementation is lame. I need enlightenment. I have users who log in. For several views I want to let them add comments. Enter act_as_commentable which does just this -- it''s polymorphic, so you

...abricator reviews to people > who might be able to review them well. I received quite a few requests > to share that script, so I've decided to do so, see > https://reviews.llvm.org/D46192. > > The script uses 2 similar heuristics to try and match open reviews with > potential reviewers: > > - If there is overlap between the lines of code touched by the > patch-under-review and lines of code that a person has written, that > person may be a good reviewer. > - If there is overlap between the files touched by the patch-under-review > and the source files that...

> > Only a single LGTM is required. Reviewers are expected to only LGTM > patches they're confident in their knowledge of. Reviewers may review > and provide suggestions, but explicitly defer LGTM to someone else. > This is encouraged and a good way for new contributors to learn the code. Whilst I get what you're trying to s...

...tructural changes, or further > comments may be appropriate. > > > > 2. If you review a patch, but don't intend for the review process to > > block on your approval, please state that explicitly. Out of courtesy, > > we generally wait on committing a patch until all reviewers are > > satisfied, and if you don't intend to look at the patch again in a > > timely fashion, please communicate that fact in the review. > > > > 3. All comments by reviewers should be addressed by the patch author. > > It is generally expected that suggested ch...

...t; comments may be appropriate. >>> > >>> > 2. If you review a patch, but don't intend for the review process to >>> > block on your approval, please state that explicitly. Out of courtesy, >>> > we generally wait on committing a patch until all reviewers are >>> > satisfied, and if you don't intend to look at the patch again in a >>> > timely fashion, please communicate that fact in the review. >>> > >>> > 3. All comments by reviewers should be addressed by the patch >>> author. >&gt...

On Fri, Nov 30, 2018 at 03:25:10PM +0100, Serge Guelton via llvm-dev wrote: > On Thu, Feb 01, 2018 at 04:47:03PM -0500, James Y Knight via llvm-dev wrote: > > That said, I do think it could make sense to prepare llvm for the world in > > which "python" is python3 on some systems. So, I'd propose the following: > > 1. Change all #! lines to say

On Mon, Nov 18, 2019 at 4:53 PM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 11/18/19 4:29 AM, James Henderson wrote: >> >> Only a single LGTM is required. Reviewers are expected to only LGTM >> patches they're confident in their knowledge of. Reviewers may review >> and provide suggestions, but explicitly defer LGTM to someone else. >> This is encouraged and a good way for new contributors to learn the code. > > Whilst I get what y...

Hello all. This is a proposal to introduce 5 new integer intrinsics: * absolute value * signed min * signed max * unsigned min * unsigned max This is motivated by the fact that we keep working around not having these intrinsics, and that constantly leads us into having more workarounds, and causes infinite combine loops. Here's a (likely incomplete!) list of motivational bugs: infinite

I have ported ASan in LLVM to Myriad RTEMS, and I would like to upstream the port. Below is the design doc. Feedback welcome. https://docs.google.com/document/d/1oxmk0xUojybDaQDAuTEVpHVMi5xQX74cJPyMJbaSaRM The port is expected to work with modified versions of RTEMS and newlib. I have a git repo with changes to those projects, that I can make available if there is interest. Here is the patch

...l err on the side of seeking more input from code owners than not. If you ask too often for trivial things, that's fine - they should hopefully get to the point where they encourage you to contribute directly/stop asking for their review/approval. But especially when asking code owners/frequent reviewers/contributors for review, be extra sure to make the patches small and clear, to have design discussion ahead of time to avoid designing in a large unwieldy code review, etc. - Dave > Philip > On 12/2/19 7:55 AM, David Blaikie wrote: > > Yeah, +1 that people from the same organization...

def create # next statement is original and is removed # @review = Review.new(params[:review]) @school = School.find(params[:school_id]) # @review = @school.reviews.create!(params[:review]) @review = @school.reviews.build(params[:review]) respond_to do |format| if @review.save flash[:notice] = ''Review was successfully created.'' #

Uh-oh: Failed to publish: GitHub error 404 on POST https://api.github.com/repos/llvm/mlir-npcomp/pulls/42/reviews: Not Found (The llvm organization may need to authorize Reviewable as an accepted third party application.) Can an admin take the suggested action on the mlir-npcomp project in the LLVM org? I've followed the instructions in this help doc

...parated out in order to smoothen the upgrade path for frontends that are maintained outside of the llvm-project repository Reviewing all of this in a single amorphous diff is something that I wouldn't wish on anybody. Conversely, having the linkage between different commits provides context to reviewers. It is also helpful to me: I can keep track of reviews to the series while simultaneously working on other changes that happen to be unrelated, and having the commits in separate stacks helps by implicitly grouping them. Admittedly this advantage is comparatively minor because the UI isn't per...

I've read "LLVM Code-Review Policies and Practices," but I remain unsure of a couple of things. Do I always wait for an actual "LGTM", or can people approve the patch for submission in other ways? What happens when a patch is approved but then there are additional review comments? Should the patch be submitted as is, then a follow-up patch submitted, or should the

...seeking more > input from code owners than not. If you ask too often for trivial things, > that's fine - they should hopefully get to the point where they encourage > you to contribute directly/stop asking for their review/approval. But > especially when asking code owners/frequent reviewers/contributors for > review, be extra sure to make the patches small and clear, to have design > discussion ahead of time to avoid designing in a large unwieldy code > review, etc. > > Hm, I see your point, but I'm not 100% in agreement. I'm trying to find > the hair to spl...

Has anyone tried out reviewable.io yet? It integrates with GitHub pull requests, but provides a separate UI for doing the review which promises to fix a lot of the issues encountered with Github's review interface. Some of the things it claims to support which seem like important additions: - Tracking the resolved status of each discussion point - Rebasing a PR without losing review history.

Hi all. I'm assuming most people reading this email are familiar with LLVM's code review process <http://llvm.org/docs/DeveloperPolicy.html#code-reviews> as well as LLVM Weekly, the development newsletter I've written and sent out every Monday since Jan 2014. Since that time, it's provided something of a "signal boost" for important mailing list discussions and