We didn't really have "code freeze" clearly defined so no one should have to be "guilty" of anything :) but that's what i'm trying to sort out here.
if we feel good that we will all be responsible to not have some gnarly, half-cocked PR coming in on code freeze week that chews up the whole week when we could(should?) be focused on: + documentation + testing - recall that we integration tests take hours and hours to execute - and thus each change that affects those force those to be re-executed + having a stable environment for the release manager to validate docs, builds, etc. + retrospective on process/procedure + planning next release cycles then we don't have an issue with code freeze week being about "merging remaining PRs". I suppose that in code review we could -1 for merge if it was half-cocked....it would just stink if that was a "critical" priority issue for that release for some reason. of course, if we were being responsible we would have identified that as a critical issue much earlier in the development cycle and it shouldn't end up coming in on Code Freeze Eve. Seems like a longshot for this to be a problem i suppose.... On Mon, Nov 9, 2015 at 8:40 AM, Daniel Kuppitz <[email protected]> wrote: > I thought of it as a week to merge remaining PR's (and do minor cleanups, > like you're planning to do for the tutorials). Code freeze means (to me), > that we don't add new things / PR's, but care more about the things that > were already done. > > Cheers, > Daniel > > > On Mon, Nov 9, 2015 at 2:21 PM, Stephen Mallette <[email protected]> > wrote: > > > We agreed on having a 1 week code freeze - yet i'm now merging PRs on > code > > freeze day. bad? > > > > I'm not sure it is. I guess it *could* have been bad if someone tried to > > jam in a massive change during code freeze week and the PR was full of > > holes and risks. Seems like we were smart enough to mitigate that for > this > > release as we carefully watched the "high-risk" JIRA tickets on the way > > into code freeze. If we continue to do that, I imagine we'd be fine, but > > all committers will have to be responsible in their choices as it > pertains > > to PRs. > > > > Anyway, just thought I'd bring it up, in case anyone had any thoughts > they > > wanted to share on procedural changes in this area. > > >
