Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D8CB7D67C for ; Wed, 1 Aug 2012 12:57:07 +0000 (UTC) Received: (qmail 36955 invoked by uid 500); 1 Aug 2012 12:57:07 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 36922 invoked by uid 500); 1 Aug 2012 12:57:07 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 36913 invoked by uid 99); 1 Aug 2012 12:57:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Aug 2012 12:57:07 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Prasanna.Santhanam@citrix.com designates 203.166.19.134 as permitted sender) Received: from [203.166.19.134] (HELO SMTP.CITRIX.COM.AU) (203.166.19.134) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Aug 2012 12:57:02 +0000 X-IronPort-AV: E=Sophos;i="4.77,694,1336348800"; d="scan'208";a="12221670" Received: from banpmailmx02.citrite.net ([10.103.128.74]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5; 01 Aug 2012 12:56:40 +0000 Received: from citrix.com (10.146.0.130) by BANPMAILMX02.citrite.net (10.103.128.74) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 18:26:39 +0530 Date: Wed, 1 Aug 2012 18:26:38 +0530 From: Prasanna Santhanam To: "cloudstack-dev@incubator.apache.org" Subject: Re: non-committer workflow Message-ID: <20120801125638.GA2940@cloud.com> Mail-Followup-To: "cloudstack-dev@incubator.apache.org" References: <59EF914C-AFDA-4C3F-9F76-3B92F0459E12@gmail.com> <501841DE.3000008@widodh.nl> <96CD3CC7-C796-4892-90DB-381077D2949E@gmail.com> <50191E01.1090302@widodh.nl> <9DC7BC0D-9388-4094-AF79-B4B7977E9BFB@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <9DC7BC0D-9388-4094-AF79-B4B7977E9BFB@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Aug 01, 2012 at 08:42:51AM -0400, Rohit Yadav wrote: > > On Aug 1, 2012, at 5:46 PM, Wido den Hollander wrote: > > > On 08/01/2012 04:50 AM, Alex Huang wrote: > >>> So currently, there are three ways for a patch to be received: > >>> 1. Email (see the workflow Wido proposed) 2. Reviewboard 3. Submitted > >>> with a bug. > >>> > >>> Email and ReviewBoard are the most visible, and it seems most people are > >>> using ReviewBoard rather than email. > >> > >> We should remove the email and submit with a bug options. > >> > > > > Are you sure? For larger patches I agree that e-mail isn't that easy, > > but it seems to work with various other projects. > > > > I personally like e-mail and 'hate' all kinds of various systems where I > > have to log in with different credentials. > > I totally agree with Wido, besides the review board workflow has a serious ownership issue: > > When I submit a git formatted patch it would strip the commit > message and author info, signature and retain only the unified diff. > The reviewer and/or committer have to do the extra work of > downloading the patch, applying/verifying it and then committing it. > During the process they may change the original commit message and > author signature (and they lose their ohloh points :) > > Further, the contributor is then required to go back and close the > submission. Well one can use their mailbox from where they can > import the patches, git am works. Or when the committer is > downloading the diff anyway, why not download the actual git > formatted patch emailed by an author and git apply? Just a > suggestion. > This was tried in the past and backfired when non-committers send through patches that get formatted by mail clients and have CRLF issues when applied by the committer. I agree Reviewboard has extra workflow involved but it integrates the review comments closely with the mailing list so it isn't as different from patches in the email in my opinion. It additionally provides pretty diff tools online. If not I would have to put the patch through my own diff tool. The current pain points as I see are : 1) ReviewBoard removes the author information from the diff 2) git am doesn't always work 3) extra workflow step of submitter closing the patch request These probably should be addressed by tooling. > > > > > If somebody finds a typo or small bug, should they really go through all > > the hoops for submitting a small patch? > > > > Imho that shouldn't be necessary. > > > > Wido -- Prasanna.,