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
