On Thu, Oct 31, 2013 at 3:45 PM, John Vines <[email protected]> wrote:
> > All of your comments make sense to me. Unfortunately we're a bit stuck in > the latter category. Going forward we can make steps as a community to help > prevent it, but that doesn't change this release. And beside issue of > pulling out an incrementally committed feature, pulling out features lends > the potential for a release to be insubstantial. > > There are 149 non-duplicate issues resolved marked for 1.6.0 that aren't marked for a 1.5.x series[1]. That a good deal, though I admittedly don't know how substantial they are, and I don't have a sense for how many would be *need* to be pulled out as part of a major feature revert. > So for the sake of the 1.6.0 release, what do we think we should do about > the sub-tasks for added/expected features? Particularly ones deemed > requisite for that feature to hit the mainline? > Ultimately, if you're the release manager you get to decide. You can just take a very permissive view on how far along things posted to review board need to be at the start. Or a permissive view on what constitutes an update "critical" for the release. I think we all want to avoid the ~5 months it took to get through RC on 1.5, but I'd be happy with even the incremental improvement we'd have by implementing Chris' suggestion on a review board choke point starting at deadline. Even if things drag on past a week, the patches that come out of those review boards will likely be far better organized than the frantic updates we saw last time. Do we have a prioritized list yet? An idea of what the assigned people think they'll hit by tomorrow night? A good list of gaps would help a great deal in this discussion. [1]: http://bit.ly/18H9jpx -- Sean
