Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MailScanner-NULL-Check: 1258024025.84772@wPRGB82aTRlReyrwSUgAGw
Message-ID: <4AF2B1D7.7090907@apache.org>
Date: Thu, 05 Nov 2009 11:07:03 +0000
From: Steve Loughran <stevel@apache.org>
User-Agent: Thunderbird 2.0.0.23 (X11/20090812)
MIME-Version: 1.0
To: general@hadoop.apache.org
Subject: Re: [VOTE] Proposed bylaws for the Hadoop project
References: <284E0999-F935-47A2-B051-7241BF8A4B39@apache.org>
	 <C715E3D7.2F176%yhemanth@yahoo-inc.com>
 <5f7f740b0911030808m3ac21126h1271b39d7ae30cac@mail.gmail.com>
In-Reply-To: <5f7f740b0911030808m3ac21126h1271b39d7ae30cac@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Owen O'Malley wrote:
> On Tue, Nov 3, 2009 at 12:12 AM, Hemanth Yamijala <yhemanth@yahoo-inc.com>wrote:
> 
>> Owen
>>
>> Some clarifications:
>>
>> In the section on "Code Change" when you mention approval as "Lazy approval
>> and then lazy consensus", did you mean the consensus will need to come into
>> play if a veto is received ?
>>
> 
> Hmm... I copied that section from Ant's bylaws. Our current practice is
> probably actually lazy consensus since we require a +1 before it can be
> committed.
> 

Ant works with commit-then-discuss, nobody works on it for a living, 
it's all voluntary, and the rate of change of the codebase is fairly 
low. There's little bureaucracy overhead to encourage code contribs -and 
every deverloper is expected to look at the commit log to see what is 
going on.

what's not spelled out in Ant's docs are that the architecture of the 
system is very compartmentalised, where it's obvious from  the source 
files what's going to break, so just by looking at the source filenames 
you can guess what the issues will be

-optional obscure SCM tasks: any changes here are welcome
-other optional stuff: those classes and subclasses may break, if they 
are used a lot review carefully
-junit : all the CI servers, lots of hate mail
-java, exec, : how code runs, lots of CI builds fail, many complaints, 
the IDE teams stop sending you xmas cards.
-<fileset> et al. complex, discuss first, tread carefully and worry 
about memory consumption
-IntrospectionHelper, TaskAdapter, the code that maps from XML to java; 
you have to really know what you are doing before going near this code, 
and unless the rest of the team trusts you, you won't get a lookin. 
Nobody touches this stuff without lots of discussion, more tests etc as 
it breaks everything
-Classpath work. Everyone worries about this, nobody really understands 
it. Anyone who says they do is probably misguided.

Because of that hierarchy, you can get a vague idea of where trouble 
will be without even reading the diffs, just looking at the subject 
lines, and if you get people with problems on optional tasks to start 
providing tests then patches, you get them fixing the problem and sucked 
into the task of codebase maintenance.

-steve