Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4E9EE780D for ; Thu, 20 Oct 2011 22:12:24 +0000 (UTC) Received: (qmail 47426 invoked by uid 500); 20 Oct 2011 22:12:23 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 47391 invoked by uid 500); 20 Oct 2011 22:12:23 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 47383 invoked by uid 99); 20 Oct 2011 22:12:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Oct 2011 22:12:23 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of yuzhihong@gmail.com designates 74.125.82.169 as permitted sender) Received: from [74.125.82.169] (HELO mail-wy0-f169.google.com) (74.125.82.169) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Oct 2011 22:12:18 +0000 Received: by wyg34 with SMTP id 34so4558658wyg.14 for ; Thu, 20 Oct 2011 15:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IITcb2o9QQEqe/Qrc5GSm5JNhA0ULlKqn2lOrknRfWA=; b=JzHkQFeTYIUc6SIOzcYyya+hSA4fOcp1AjjZad34tCP0OIBW6VPewWMlJhrNuhE0au p3zokzOlbkzXKdOWvHOOXkM+U9h/nwZYfLKy9u/6pOkMFaIpN53LBxUwMbqS5o9ypdvk emRAzdyO64fCrry3SsVd1A69up5hU09RZyPoI= MIME-Version: 1.0 Received: by 10.216.15.14 with SMTP id e14mr9400206wee.21.1319148717112; Thu, 20 Oct 2011 15:11:57 -0700 (PDT) Received: by 10.216.17.208 with HTTP; Thu, 20 Oct 2011 15:11:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 15:11:57 -0700 Message-ID: Subject: Re: suggestion for smoother code review process From: Ted Yu To: dev@hbase.apache.org Content-Type: multipart/alternative; boundary=0016e64c0b68b07cd304afc23e06 --0016e64c0b68b07cd304afc23e06 Content-Type: text/plain; charset=ISO-8859-1 I think the easiest improvement is to strip the list of files from reviewboard feedback. I would wait for a while to see if any volunteer comes up for the above task :-) I am not sure about phabricator which requires an account. I remember seeing phabricator feedback in JIRA. The format is different. Cheers On Thu, Oct 20, 2011 at 3:05 PM, Todd Lipcon wrote: > Hey Ted, > > I agree the formatting of the reviewboard comments back onto JIRA > could be improved. I wrote the original script that does it - it's > some nasty procmail and python. > > It sounds like the FB folks are working on getting phabricator up - > maybe it will have better JIRA integration? > > Let me know if you have some time to spend on improving the > python/procmail setup with RB. I can connect you with the right infra > people to make the change. > > -Todd > > On Thu, Oct 20, 2011 at 3:03 PM, Ted Yu wrote: > > Hi, > > We have been using review board for a while to conduct code review. > > One aspect I don't like the integration is that every round of review > would > > result in the summary and list of files (both of which could be long) to > be > > reposted to JIRA. > > For a large project, such as HBASE-2856 or HBASE-3777, it is impossible > > (without exaggeration) for a developer who didn't closely follow the > > development to understand what was going on. > > > > I want to share what I have been doing recently (by not commenting on > review > > board, if possible): > > I would quote the snippet of code in the patch and make my comment > > > > I think the person asking for review can post the url for review board > > request on the JIRA. By not filling Bugs field, we don't incur extra > > housekeeping that I mentioned earlier. > > If the Groups and People fields are filled properly, there is no risk of > > losing review request. In the worst case, one sentence on the JIRA can > > remind related people to look at the patch again. > > > > Note the above is just personally advice. Please don't interpret it as > rule > > or anything like that. > > > > Cheers > > > > > > -- > Todd Lipcon > Software Engineer, Cloudera > --0016e64c0b68b07cd304afc23e06--