On Thu, Oct 31, 2013 at 2:26 PM, Sean Busbey <[email protected]> wrote:
> On Thu, Oct 31, 2013 at 12:41 PM, Sean Busbey <[email protected]> wrote: > > > On Thu, Oct 31, 2013 at 12:37 PM, Christopher <[email protected]> > wrote: > > > >> I think a week extension would be good for projects that are under > >> review, but I don't think it should be extended for development on > >> those features (except to address issues from the review). This would > >> also encourage people to push something potentially disruptive to > >> ReviewBoard instead of committing at the last minute and having to > >> revert it later. That would allow us to review stuff that has been > >> ready, but not committed because people have been busy finishing other > >> features for the feature freeze and haven't had time to review it yet. > >> > >> > > Just to make sure I'm reading this right: > > > > you're saying we include things that are in review board as of the > > original feature freeze date? And then they get pushed > post-feature-freeze > > date once their reviews have iterated to acceptance? > > > > > > > > If I am interpreting Chris' proposal correctly, I like it better than a > general one week extension. > > In addition to the benefits he lists, I think it also makes us much more > likely to get 1-commit-per-ticket, which I'm a huge fan of. > > -- > Sean > So I am interpreting it as all code modifications must be into the codebase or review board by the freeze date. Which could be beneifical, however- 1. What about the case where a patch needs to be modified? What if it's a really minor change vs. a major change? Where's the line? 2. In the case of features that have multiple subtasks, they have complementing features that NEED to exist to make the main feature usable/maintainable. What happens if we don't get those in?
