Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Date: Wed, 6 Feb 2013 13:39:26 -0500
From: Chip Childers <chip.childers@sungard.com>
To: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
Cc: Koushik Das <koushik.das@citrix.com>,
	"cloudstack-dev@incubator.apache.org" <cloudstack-dev@incubator.apache.org>,
	Alex Huang <Alex.Huang@citrix.com>,
	Abhinandan Prateek <Abhinandan.Prateek@citrix.com>
Subject: Re: [PROPOSAL] Raise cluster size limit to 16 on VMware
Message-ID: <20130206183926.GB94758@USLT-205755.sungardas.corp>
References: 
 <2529883E7B666F4E8F21F85AADA43CA7010C92B686E8@BANPMAILBOX01.citrite.net>
 <CD37DD49.6DF5%chiradeep.vittal@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CD37DD49.6DF5%chiradeep.vittal@citrix.com>
User-Agent: Mutt/1.4.2.3i

On Wed, Feb 06, 2013 at 10:16:33AM -0800, Chiradeep Vittal wrote:
> +1. I feel we should do right by these submissions.
> 

If there are specific submissions that you want to propose for
inclusion, please do.  As I said in my reply to Koushik, anyone can
propose anything.  Concensus is what will matter.

With my RM hat on, I'm trying to keep the process going, based on the
latest community consensus of what our process should be.  I don't have
a particular interest or disinterest in any of the features sitting in
reviewboard right now, so I'd expect those that do to speak up.

> On a related note, should we have sub-milestones for the 4.2 release so
> that we don't have a stampede of feature merges at feature freeze?

I sort of replied to this point in my last email, but I'll do it again
here.

Yes, I think it would be helpful.  But the most important thing for a
contributor to do, is to work to get concensus on their change and
support for a review and commit of that patch.

Committers, especially those that could be (and have been) called
maintainers of certain areas of the code, should also be more responsive
to review requests.

Whomever does the RM for 4.2.0 should try to lay out some reasonable
milestones that help inform people's expectations around timing.

-chip