<div dir="ltr">TL;DR:<br><br>* code freeze for all projects&#39; master branches starts <b>today at 2pm PST / 5pm EST / 11pm CST</b>.<div>* <b>code freeze lifts on Wed</b>, May 25 after the Demo calls, at the start of Sprint 115.</div><div>* you <b>don&#39;t need to create a branch</b> or update your root pom to a newer parent pom (yay, less process!)</div><div>* <b>build will run Thursday night</b> and be copied to /staging/ on Friday morning EST.</div><div>* <b>From Fri to Wed, you should *NOT* push anything into master branch</b>; instead, see below for other work you can do to close out the sprint</div><div><br></div><div>----<br><br>As Sprint 114 is done on Wed, May 25 (and we need something that&#39;s demoable that day!), it&#39;s time again to do a code freeze in master so that I can build the latest CI bits (Thurs), pull them tomorrow (Fri), turn that into something staged for QE to test (Mon), and then demo (Tues).<br><br>So, here&#39;s how that will work:<br><br>* we will not create branches<br>* we will just pull the latest bits from master -- whatever is committed as of 2pm PST / 5pm EST / 11pm CST is what will be built.<br>* we will use parent pom 4.4.0.Alpha1-SNAPSHOT - no Task JIRA needed to change this to Alpha2<br>* no root pom changes in each project are needed (we&#39;ll use 4.4.0.Alpha1-SNAPSHOT) - again, no Task JIRA needed<br>* features and plugins will still be called &quot;Alpha1&quot;, not &quot;Alpha2&quot;. This is simply to denote QUALITY, not to identify WHICH sprint/milestone. <br><br>This code freeze will continue until Wed, May 25 when this sprint (Sprint 114) ends &amp; the next one (Sprint 115) starts. <br><br>If you have things you need to commit on Friday, here&#39;s how you can keep working without losing productivity:<br><br>* leave those commits in a PR or topic branch. Have a bunch of commits that depend on others? Create a &quot;testing&quot; branch and push everything there; then at the start of the next sprint, merge testing -&gt; master.<br>* work on doc or N&amp;N<br>* write a blog</div><div>* create a screencast / demo of your latest accomplishments!<br>* do some usability testing of your component or some other component<br>* use your tools! open some JIRAs if you find problems!<br>* JIRA cleanup/triage<br>* plan for the next sprint<br><br>Freaked out? Talk to Max or Alexey. They agree it&#39;s useful to do the above things at least ONCE every 3 weeks instead of at the end of the release. Welcome to Agile. :D</div><div><br></div><div><br>What&#39;s the process we&#39;ll use for this build? I will:<br><br>* build everything Thursday night,<br>* disable the jobs Friday morning,<br>* copy bits from /snapshots/ to /staging/AlphaX/,<br>* announce it to QE, &amp;<br>* re-enable the jobs<br>* tag the projects using the SHAs used to produce the build<br><br>Note that the staging folder will be called Alpha2, as this is a &quot;productization&quot; step and is not dependent on parent pom or BUILD_ALIAS. I want to split the notion of &quot;what the bits are called&quot; from &quot;what the release is called&quot; since that&#39;s the direction Program Management is heading. <br><br>---<br><br>Aside: I&#39;m going rock climbing north of Montreal for the long weekend (Monday is a holiday here in Canada) so I&#39;ll be working late<br>tonight &amp; offline by about 2pm tomorrow. Won&#39;t be online again until Tuesday morning. If anything goes seriously wrong, ping Mickael or Alexey. :D<br><br>Thanks for reading this far!<br><br>--<br>Nick Boldt :: JBoss by Red Hat<br>Productization Lead :: JBoss Tools &amp; Dev Studio<br><a href="http://nick.divbyzero.com">http://nick.divbyzero.com</a></div></div>