search for: reviewables

...thin console: =========== >> u = User.find(:first) my user stuff >> r = Review.find(:first) my review stuff >> u.reviews << r added r to u''s reviews I check the "reviews" table, and the review is successfully entered... however, there is no entry in "reviewables". I''ve played around with this for quite a while trying to debug why an insert isn''t happening into this table, but no dice. Any insight into this would be greatly appreciated ! == Dylan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://w...

Hi, At the last EuroLLVM, I gave a lightning talk about code review statistics on Phabricator reviews and what we could derive from that to try and reduce waiting-for-review bottlenecks. (see https://llvm.org/devmtg/2018-04/talks.html#Lightning_2). One of the items I pointed to is a script we've been using internally for a little while to try and match open Phabricator reviews to people who

Hi, everyone, I've been fielding an increasing number of questions about how our code-review process in LLVM works from people who are new to our community, and it's been pointed out to me that our documentation on code reviews is both out of date and not as helpful as it could be to new developers.   http://llvm.org/docs/DeveloperPolicy.html#code-reviews I would like to compose a

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

I just saw this, and I have to say -- thanks, Kristof! Do you know if this is something that could be automated in Phabricator, instead of something that people run on their own? Or is the intent of this to be something that ran regularly (say, weekly or daily) that would email people (or the list) that could be doing the reviews for some of the open patches? On Sat, Apr 28, 2018 at 1:01 AM,

> > 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 say, I'm not particularly comfortable with

+1 in general, and Philip has good suggestions as well! -- Mehdi On Sat, Nov 16, 2019 at 8:37 AM Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > + 1 in general, a couple of suggestions > > On 11/14/19 7:46 PM, Finkel, Hal J. via llvm-dev wrote: > > Hi, everyone, > > > > I've been fielding an increasing number of questions about how our

Yeah, +1 that people from the same organization are sometimes the only ones working on a certain feature/area. (certainly I'd expect some discussion about the feature in general to be discussed outside that group if it's in any way contentious - but some stuff's clear enough (I think I implemented debug_types years ago, likely with only Eric's approval, both of us being at Google

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.

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

On Mon, Dec 2, 2019 at 12:52 PM Philip Reames <listmail at philipreames.com> wrote: > Mehdi, David, > > I think you're both pointing out exceptions rather than the general rule. > I tried to indicate their might be reasonable exceptions (see the second > sentence past Mehdi's quote), but in general, particularly for new > contributors, I think it is important we

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

...ion.) 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 <https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/requesting-organization-approval-for-oauth-apps> and requested that reviewables be granted access to the LLVM organization. I'm not completely aware of how this will show up on the admin side. +LLVM Administration List <llvm-admin at lists.llvm.org> [image: image.png] I'm far from an expert user of reviewable after one review, but I found it wholly superior to...

Hi David, On Wed, Jan 15, 2020 at 12:51 PM David Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I would like to understand better how people use Phab's advanced > features and why. For example, what drives the need for patch series > and dependence relationships? Some walk-through examples would be very > helpful. Here's a somewhat more complex example of

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

On Mon, Dec 2, 2019 at 8:23 PM Philip Reames <listmail at philipreames.com> wrote: > > On 12/2/19 10:05 AM, David Blaikie wrote: > > > > On Mon, Dec 2, 2019 at 12:52 PM Philip Reames <listmail at philipreames.com> > wrote: > >> Mehdi, David, >> >> I think you're both pointing out exceptions rather than the general >> rule. I tried

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