+1. I feel we should do right by these submissions. 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?
On 2/6/13 10:08 AM, "Koushik Das" <koushik....@citrix.com> wrote: >Chip, > >I get your point. But what this essentially means is that the effective >cut-off date for all non-committers is at least a week (assumption is >there will be 2-3 iterations each taking 2 days and committers themselves >will be busy) before the actual one. Either this needs to be clearly >communicated for future releases OR another option is to let selective >patches in based on state of the code and consensus in the community. > >-Koushik > >> -----Original Message----- >> From: Chip Childers [mailto:chip.child...@sungard.com] >> Sent: Wednesday, February 06, 2013 10:30 PM >> To: Alex Huang >> Cc: Abhinandan Prateek; Koushik Das; cloudstack-dev@incubator.apache.org >> Subject: Re: [PROPOSAL] Raise cluster size limit to 16 on VMware >> >> On Wed, Feb 06, 2013 at 08:49:39AM -0800, Alex Huang wrote: >> > I've cced Chip in case he knows this was decided already. >> > >> > To me reviewboard not being committed to 4.1 is a problem with the >> community following up on patches and not with the original submit of >>the >> patch. The submitter obviously submitted the patch in time (some has >>been >> there for a long time) so should we make it an exception for review >>board >> submits that made it in time to make it into the release? >> > >> > If not, then next release we should set a deadline for review board >>patches >> earlier than feature freeze deadline. >> > >> > --Alex >> >> We didn't decide this yet, but IMO it's an unfortunate but necessary >>situation >> for us to not include this feature in 4.1. >> >> We really need to get much better about being responsive to reviewboard >> submissions. That being said, I still believe that the freeze is >>against the state >> of master. >> >> As an example, there were several ongoing discussions around different >> features that lead to the patches not making it into the release in time >> already. The reason that we want to have a cutoff date is to make sure >>that >> we have a chance of actually testing and stabilizing on a reasonable >>schedule. >> >> The best advice I have for us, is that feature submissions need to >>happen as >> soon as possible, so that reviews can commence and issues can be sorted >> out. Incrementally showing progress and getting reviews from the >> community should happen throughout the feature dev process. >> >> Don't forget the reason for time-based releases is that features can >>simply >> be in the *next release*. >> >> Lots of things need to improve, but my (unfortunate perhaps) vote is >>that >> freeze means just that. We froze features for the release branch based >>on >> what was actually in master. >> >> -chip
