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
