Avoiding mega-patches

[Owen O'Malley <om...@apache.org>]

Hi all,
    Looking through the Hive jiras, I found HADOOP-4320, which is a  
huge jira that seems to have rolled multiple issues into one. I  
understand in the rush to get Hive committed, bigger patches were  
easier, but they make it very difficult to track what is happening in  
the project. Never mind that reviewing a 1.5 mb patch is almost  
impossible. It is also very hard for the PMC to know who did what. For  
instance, 4320 is assigned to Ashish, but was uploaded by Joydeep.  
 From the comments, it seems that they both did parts of the mega- 
patch. In the future, please commit the patches for separate issues  
separately.

Thanks,
    Owen

Re: RE: Avoiding mega-patches

[Doug Cutting <cu...@apache.org>]

Ashish Thusoo wrote:
> We will be careful about this in future. We have had 3-4 mega drops
> (including the first one, these mega drops actually contain fixes from a
> whole number of people) and part of the reason was that the turn around
> through hudson and the JIRA was too large for us to be able to swiftly
> deploy the codeand bug fixes into production at facebook (yes, we are
> pretty much running the latest hive code in production here).

The turnaround through Hudson and Jira is a cost of doing business at 
Apache.  In a crunch, folks can attach a record of a successful test run 
to Jira, but a successful Hudson run is preferred.

Each issue should address a single concern.  The author(s) of a patch 
must be clearly identified if they are other than the person who 
attaches the patch.  Patches that fix multiple issues should be avoided.

Contributors must demonstrate clear understanding of Apache's ways with 
a consistent record of high-quality patches before they can become 
committers.  These mega patches are steps away from that goal.

Doug

RE: Avoiding mega-patches

[Ashish Thusoo <at...@facebook.com>]

Hi Owen.

We will be careful about this in future. We have had 3-4 mega drops (including the first one, these mega drops actually contain fixes from a whole number of people) and part of the reason was that the turn around through hudson and the JIRA was too large for us to be able to swiftly deploy the codeand bug fixes into production at facebook (yes, we are pretty much running the latest hive code in production here). Having said that, we realize the confusion it causes and we will be more careful about this.

Ashish

________________________________________
From: Owen O'Malley [omalley@apache.org]
Sent: Thursday, November 13, 2008 2:29 PM
To: hive-dev@hadoop.apache.org
Subject: Avoiding mega-patches

Hi all,
    Looking through the Hive jiras, I found HADOOP-4320, which is a
huge jira that seems to have rolled multiple issues into one. I
understand in the rush to get Hive committed, bigger patches were
easier, but they make it very difficult to track what is happening in
the project. Never mind that reviewing a 1.5 mb patch is almost
impossible. It is also very hard for the PMC to know who did what. For
instance, 4320 is assigned to Ashish, but was uploaded by Joydeep.
 From the comments, it seems that they both did parts of the mega-
patch. In the future, please commit the patches for separate issues
separately.

Thanks,
    Owen