search for: reviewer

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 t...

...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 rev...

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 tha...

> > 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...

...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 c...

...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. >&g...

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...

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.'' #

...;> sequence of events happened: >>> >> >>> >> 1. PR was opened with a series of commits, one of which (call it >>> >> commit B for base) is non-trivial and under review separately as a >>> >> different PR. >>> >> 2. Other reviewer makes comments, asks for some refactoring changes. >>> >> 3. Author makes those changes, adds them as a fixup commit. >>> >> 4. I can now no longer usefully review the PR, because I only have two >>> >> options, both of which are similarly useless: >&...

...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 pe...

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 sp...

...ther GitHub project, where this > >> sequence of events happened: > >> > >> 1. PR was opened with a series of commits, one of which (call it > >> commit B for base) is non-trivial and under review separately as a > >> different PR. > >> 2. Other reviewer makes comments, asks for some refactoring changes. > >> 3. Author makes those changes, adds them as a fixup commit. > >> 4. I can now no longer usefully review the PR, because I only have two > >> options, both of which are similarly useless: > >> 4a. I look at a...

...ack can put people off contributing to LLVM. As was pointed out in response to the last RFC, very long review times are problems for long-time contributors as well as newcomers. My proposal is simple: add a new 'Review corner' section to LLVM Weekly to help highlight patches that need more reviewer input. There are two main categories I'd like to focus on: 1) patches from first-time contributors 2) patches where review activity has died off (i.e. they're 'stuck'). Obviously this is something that I can just go ahead and do, but I'd appreciate feedback on whether this woul...