> 1. You have all your PRs voted on and merged by the date/time of the code freeze.
if we do that then I'd say that the PR would need to be issued 72 hours prior to code freeze. since we are in the informal pattern of starting a release on a Monday, then that means that all PRs should be in the Thursday before a code freeze week thus allowing them to be voted/merged by the Sunday (with the preference that we do that on the Friday as opposed to weekend). On Mon, Nov 9, 2015 at 10:20 AM, Marko Rodriguez <[email protected]> wrote: > Hi, > > Code Freeze. > > 1. You have all your PRs voted on and merged by the date/time of > the code freeze. > 2. The repo can only be tweaked with test cases and documentation. > - Not cause you slacked on your PRs. > - But because you are just going over and over and over > and over the work and tweaking on it to enhance it more. > > Finally, don't procrastinate. If you really are the type of person that > tries to get their PRs in on the last day, make sure you have all your work > integration tested (no "mvn clean install worked?!"). > > Thanks, > Marko. > > http://markorodriguez.com > > On Nov 9, 2015, at 6:56 AM, Stephen Mallette <[email protected]> wrote: > > > 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. > >>> > >> > >
